Лекція №22. VLІW архітектура

Клиент-серверные приложения

Файл-серверные приложения

Общая классификация архитектур информационных приложений

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

Рассмотрим классификацию возможных архитектур информационных систем:

· выделенные файл-серверы, серверы баз данных;

· клиент-серверные приложения, на основе серверов БД;

· ИС базирующиеся на технологии Internet (Intranet-приложения);

· концепция "склад данных" (DataWarehouse) - интегрированная информационная среда, включающая разнородные информационные ресурсы.

· архитектура предназначеная для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

С терминологией в области информационных систем вообще, а русскоязычной терминологией в особенности дела обстоят неважно. Область информационных систем очень быстро развивается. Практически каждый год возникают новые технологии и архитектурные решения, для которых в маркетинговых целях придумываются оригинальные, привлекающие внимание названия, далеко не всегда точно отражающие смысл технологии и/или архитектуры. На самом деле, все подходы к организации информационных систем, рассматриваемые в этом курсе базируются на общей архитектуре "клиент-сервер". Различие состоит только в том, что делают клиенты и серверы. Тем не менее, чтобы не запутать читателя, далее мы вынуждены применять русскоязычные эквиваленты соответствующих англоязычных терминов.

Привлекательность такой организации архитектуры ИС для разработчиков информационных систем заключается в том, что при опоре на файл-серверные архитектуры сохраняется автономность прикладного (и большей части системного) программного обеспечения, работающего в каждой локальной сети. Фактически, компоненты информационной системы, выполняемые на разных ПК, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждого рабочего места дублируются не только прикладные программы, но и средства управления базами данных. Файл-сервер представляет собой разделяемое всеми компьютерами комплекса расширение дисковой памяти (рисунок 2.1).

Рис. 2.1. Классическое представление информационной системы в архитектуре "файл-сервер"

Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях (знакомая операционная система и известная аппаратная платформа). Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. (Как гласит русская пословица, "Простота хуже воровства", а здесь мы, как правило, имеем простоту на основе воровства программных продуктов).

Для работы ИС требуется спроектировать базу данных. Часто разработчики файл-серверных приложений этим пренебрегают, что может привести к неэффективному использованию информационной системы. Сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области.

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

· наличие транзакционного управления,

· хранение избыточных данных (например, с применением методов журнализации),

· возможность формулировать ограничения целостности и проверять их соблюдение.

В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рисунок 2.2).

Рис. 2.2. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре

Выводы. Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Очень часто для небольшой компании для ведения, достаточно иметь изолированную систему, работающую на отдельном ПК. Но при такой технологии требуется большая аккуратность конечных пользователей для надежного хранения и поддержания целостного состояния данных. Однако, в уже ненамного более сложных случаях такая технология становятся недостаточной.

Под клиент-серверным приложением понимают информационную систему, основанную на использовании серверов баз данных.

Под сервером баз данных будем понимать программное образование, привязанное к соответствующей базе (базам) данных, существующее, независимо от существования пользовательских (клиентских) процессов и выполняемое, на выделенной аппаратуре (мы намеренно используем не очень конкретные термины "программное образование" и "выделенная аппаратура", потому что их конкретное воплощение различается в разных серверах баз данных).

Такие серверы баз данных существенно сложнее по организации, чем СУБД-ФС, на зато обеспечивают более тонкое и эффективное управление базами данных.

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

Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 2.3.

Рис. 2.3. Общее представление информационной системы в архитектуре "клиент-сервер"

Комментарии к рисунку:

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

· Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.

Интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения.

Клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL.

VLІW (Very Large Іnstructіon Word - надвелике командне слово) – це набір команд, що реалізує горизонтальний мікрокод. Декілька (4-8) простих команд упаковуються компілятором у довге слово. Таке слово відповідає набору функціональних пристроїв. VLIW- архітектуру можна розглядати як статичну суперскалярну архітектуру, оскільки розпаралелювання коду виробляється на етапі компіляції, а не динамічно під час виконання. Тобто в машинному коді VLІW є присутнім явний паралелізм.

Хоча ідеї VLІW сформульовані вже давно, дотепер вони були відомі в основному фахівцям в області комп'ютерних архітектур. Наявні реалізації, наприклад, VLІW Multіflow, не одержали широкого поширення. Мабуть, єдиними популярними процесорами, архітектура яких близька до VLІW, була лінія AP- 120B/ FPS-164/FPS-264 компанії Floatіng Poіnt Systems. Ці процесори в 1980-ті роки активно застосовувалися при проведенні науково-технічних розрахунків.

Команда в цих системах містила ряд полів, кожне з яких управляло роботою окремого блоку процесора, так що все командне слово визначало поводження всіх блоків процесора. Однак довжина команди в FPS- Х64 була дорівнює всього 64 розрядам, що по сучасних мірках ніяк не можна віднести до надвеликого.

Виділення в архітектурі VLІW компонентів командного слова, керуючих окремими блоками МП, уводить явний паралелізм на рівні команд. Завдання забезпечення ефективного розпаралелювання роботи окремих блоків покладають при цьому на компілятор, що повинен згенерувати машинні команди, що містять явні вказівки на одночасне виконання операцій у різних блоках. Таким чином, досягнення паралелізму, забезпечуване в сучасних суперскалярних RISC-процесорів їхньою апаратурою, в VLІW покладає на компілятор. Очевидно, що це викликає складні проблеми розробки відповідних компіляторів. При цьому розпаралелювання роботи між ФУ в EPІ відбувається статично при компіляції, у те час як сучасні суперскалярні RІSC-процесори здійснюють це динамічно.

Дата добавления: 2013-12-12