Лабораторная работа 4 построение приложений информационных систем с различными вариантами архитектур
 Скачать 377.02 Kb.
|
|
1 Лабораторная работа № 4 ПОСТРОЕНИЕ ПРИЛОЖЕНИЙ ИНФОРМАЦИОННЫХ СИСТЕМ С РАЗЛИЧНЫМИ ВАРИАНТАМИ АРХИТЕКТУР Цель работы: изучение и практическая реализация широко используемых архитектур информационных систем. Программа работы 1. Изучение теоретического материала. 2. Написание сетевых приложений ИС с выбранной архитектурой. 3. Отладка программы. Пояснения к работе В источниках существуют различные определения "архитектуры информационных систем" [4,5]. Архитектура – это организационная структура системы. Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. В данной лабораторной работе рассмотрим из существующей классификации информационных систем наиболее широко используемые архитектуры: файл-серверную, клиент-серверную и Web-архитектуру. 4.1. Архитектура "файл-сервер" Файл-серверные приложения схожи по своей структуре с локальными приложениями, но в отличие от них используют сетевой ресурс для хранения программ и данных. 2 Функции сервера: хранения данных и кода программы. Функции клиента: обработка данных происходит исключительно на стороне клиента. Классическое представление информационной системы в архитектуре "файл-сервер" представлено на рис.4.1 Рис. 4.1. Классическое представление архитектуры "файл-сервер" Организация информационных систем на основе использования выделенных файл-серверов все еще является распространенной в связи с наличием большого количества персональных компьютеров (ПК) разного уровня развитости и сравнительной дешевизны связывания ПК в локальные сети. Конечно, основным достоинством данной архитектуры является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде Windows или какого-либо облегченного варианта Windows Server. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных (СУБД). Достоинства файл-серверной архитектуры: - многопользовательский режим работы с данными; 3 - удобство централизованного управления доступом; - низкая стоимость разработки; - высокая скорость разработки; - невысокая стоимость обновления и изменения программного обеспечения (ПО). Недостатки: - проблемы при многопользовательской работе с данными, последовательный доступ, отсутствие гарантии целостности; - низкая производительность (зависит от производительности сети, сервера, клиента); - большая загруженность сетевого трафика, т.к. обработка данных происходит в основном на стороне клиента; - плохая возможность подключения новых клиентов; - ненадежность системы. Простое файл-серверное приложение, работающее с небольшими объемами информации и рассчитанное на применение в многопользовательском режиме, можно спроектировать, разработать и отладить очень быстро. Для небольшой компании – это будет эффективная и полезная система. Однако в рамках средних и крупных предприятий для поддержки информационной системы, обслуживаемой большими группами пользователей, файл-серверные архитектуры становятся недостаточными. 4.2. Архитектура "клиент-сервер" Клиент-сервер – сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемых серверами, и заказчиками услуг, называемых клиентами. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением. Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре. Под клиент-серверным приложением в этом случае понимается информационная система, основанная на использовании серверов баз данных. Схематически такую архитектуру можно представить, как показано на рис 4.2. 4 Рис. 4.2.Классическое представление архитектуры "клиент-сервер" На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты и выполняющие другие специфичные для приложения функции. Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения сервера баз данных, поддерживаемого конкретной для приложения СУБД. Как правило, интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения. Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверуБД, передавая ему текст оператора языка SQL.Далее на стороне сервера баз данных выполняются следующие действия: - производится компиляция полученного оператора; - если компиляция завершилась успешно, происходит выполнение оператора. Преимуществами данной архитектуры являются: 5 - возможность, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети; - все данные хранятся на сервере, который, как правило, защищен гораздо лучше большинства клиентов, а также на сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа; - поддержка многопользовательской работы; - гарантия целостности данных. Недостатки: - администрирование данной системы требует квалифицированного профессионала; - высокая стоимость оборудования; - бизнес-логика приложений осталась в клиентском ПО. Данный вид архитектуры еще называют архитектурой с "толстым" клиентом. 4.3. Многоуровневый "клиент-сервер" Многоуровневая архитектура клиент-сервер – разновидность архитектуры клиент-сервер, в которой функция обработки данных (основная бизнес-логика) вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (ее еще называют "тонкий" клиент), предполагающая наличие клиентского приложения (терминала ) , подключенного к серверу приложений, который в свою очередь подключен к серверу базы данных. Схематически такую архитектуру можно представить, как показано на рис 4.3. 6 Рис. 4.3. Трехуровневая архитектура "клиент-сервер" Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень архитектуры и собственно приложение для конечного пользователя. Первый уровень не имеет прямых связей с базой данных (по требованиям безопасности) и не нагружен функциональной бизнес-логикой (по требованиям масштабируемости). На первый уровень обычно выносится: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал. Сервер приложений располагается на втором уровне. На этом уровне сосредоточена большая часть бизнес-логики. Остальные ее фрагменты, экспортируются на терминалы, а также в виде хранимых процедур и триггеров на третий уровень – сервер БД. Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных. 7 В простейшей конфигурации физически сервер приложений может быть совмещен с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов. В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы. Достоинством данной архитектуры является : - клиентское ПО не нуждается в администрировании; - масштабируемость; - конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней; - высокая безопасность; - высокая надежность; -низкие требования к скорости канала (сети) между терминалами и сервером приложений; -низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Недостатки: - растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание; - более высокая сложность создания приложений; - сложнее в разворачивании и администрировании; -высокие требования к производительности серверов приложений и сервера базы данных, а значит и высокая стоимость серверного оборудования; - высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений. 4.4. Архитектура Web-приложений 8 Обычно Web-приложения создаются как приложения в архитектуре "клиент-сервер" (“тонкий” клиент), но серверная часть имеет различные архитектурные решения [5]. Схематически такую архитектуру в трехзвенном варианте можно представить, как показано на рис.4.4. Рис. 4.4.Архитектура Web-приложений В начале конфигурация World Wide Web (WWW) виделась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могли бы общаться между собой". Поэтому первые Web -приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Вторым этапом развития Web-технологий стало появление понятия приложений, которые базировались на таких интерфейсах как CGI (Common Gateway Interface) или FastCGI. CGI – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения. Входной информацией для таких приложений служило содержимое HTTP-заголовка. CGI-приложения генерировали HTML- код, который возвращался браузеру. Основной проблемой CGI- приложений было то, что при каждом клиентском запросе сервер выполнял эти приложение в реальном времени, загружая ее в 9 отдельное адресное пространство, а это сказывалось на производительности работы CGI-приложений. Появление технологии Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Web -приложений, в которых, в зависимости от каких-либо клиентских действий (запросов), выполнялся серверный код. Также стала возможной динамическая генерация содержимого Web -страниц и их наполнение перестало быть чисто статическим. Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Web-сервера. У таких серверов других фирм через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Web-серверов Netscape этот программный интерфейс называется NSAPI (Netscape Server API). У довольно распространенного Web-сервера Apache также имеется возможность выполнять Web-приложения, реализованные в виде библиотек, которые именуются Apache DSO (Dynamic Shared Objects). Дальнейшим развитием использования как CGI-, так и ISAPI- приложений является разработка нового, высокоуровневого интерфейса второго типа Web-приложений, который упростил задачи генерации HTML-кода, позволил обращаться к его компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI- фильтра. Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Web-странице присутствуют фрагменты кода, который интерпретируется Web-сервером и пользователь получает результат выполнения этих фрагментов кода. Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Web-страницы кода, выполняемого Web-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) 10 при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер. Новейшая версия технологии Active Server Pages – ASP.NET, являющаяся ключевой в архитектуре Microsoft.NET Framework. С помощью ASP.NET можно создавать Web-приложения и Web-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами, могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Web-приложений. В общем случае клиентом Web-сервера может быть не только персональный компьютер, оснащенный обычным Web-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Web-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк текста), для них существуют и другие протоколы передачи данных: WAP (Wireless Access Protocol) и соответствующие языки разметки WML (Wireless Markup Language), СHTML – (Compact HTML) и т.д. При этом возникает задача передачи данных на мобильное устройство в соответствующем формате. Для этой цели существуют специализированные сайты, либо происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, в формат XSLT). Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP.NET. Третьим этапом развития клиентских частей Web-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Web-браузере. В частности, современные Web-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP- 11 код, размещается на Web–странице. Этот код интерпретируется уже не Web -сервером, а браузером и соответственно выполняется на клиентском устройстве. Отметим, что с ростом объема используемых данных и числа посетителей Web-сайтов возрастают и требования к надежности, производительности и масштабируемости Web-приложений. Четвертым этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Web-приложении от его интерфейса. В этом случае в самом Web-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" (B2C – business-to-consumer) или задачи интеграции Web-приложений с целью реализации схемы "предприятие-предприятие" (B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки. Следующим этапом эволюции Web-приложений, помимо доступа к корпоративным данным и данным партнеров, стало получение доступа к корпоративным приложениям. Для решения этой задачи интеграции Web-приложений с внутренними информационными системами предприятий и с приложениями, обеспечивающими взаимодействие с клиентами и партнерами, используются специальные среды, называемые корпоративными порталами. Нередко частью портального решения являются средства управления информационным наполнением Web-сайта – объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными "вручную" не представляется возможным. 12 Обобщая вышесказанное, можно выделить основные особенности Web-архитектуры. Достоинство : - отсутствие необходимости использовать дополнительное ПО на стороне клиента, что позволяет автоматически реализовать клиентскую часть на всех платформах; - возможность подключения практически неограниченного количества клиентов; - благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных; - доступность при работоспособности сервера и каналов связи; - архитектура Web-систем не имеет существенных ограничений относительно объема данных. Недостатки : - недоступность при отсутствии работоспособности сервера или каналов связи; - относительно низкая скорость Web-сервера и каналов передачи данных в сравнении с локальными сетями. Задания к лабораторной работе 1. Разработать и отладить сетевое приложение, реализующее файл-серверную архитектуру. 2. Разработать и отладить сетевое приложение, реализующее двухуровневуюклиент-серверную архитектуру. 3. Разработать и отладить сетевое приложение, реализующее трехуровневуюклиент-серверную архитектуру. 4. Разработать и отладить сетевое приложение, реализующее трехуровневуюWeb- архитектуру. Требования к оформлению результатов лабораторной работы Выполнение каждой лабораторной работы заканчивается отчетом , который должен включать : 13 - цель; - задание; - краткое пояснение к работе; - блок-схему алгоритма программы; - листинг программы; - пример работы программы; - выводы. |