Логические слои программного обеспечения распределенных информационных систем

Размещено на http://www.allbest.ru/

РЕФЕРАТ

по дисциплине «Информатика»

на тему «Логические слои программного обеспечения распределенных информационных систем»

Содержание

1. Логические слои программного обеспечения распределенных информационных систем.

2. Виды архитектуры распределенных информационных систем. Одно- и двухярусные системы.

3. Трехярусные и многоярусные архитектуры распределенных информационных систем.

4. Синхронное и асинхронное, блокирующее и неблокирующее взаимодействие в распределенных информационных системах.

5. Принципы реализации удаленного вызова процедур. Основные проблемы реализации.

1. Логические слои программного обеспечения распределенных информационных систем

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

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

1) презентационный слой,

2) слой прикладной логики,

3) слой управления ресурсами.

Слои могут быть абстрактными, но могут быть четко видимы в программном обеспечении в виде отдельных подсистем.

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

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

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

2. Виды архитектуры распределенных информационных систем

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

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

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

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

Многопользовательские однозвенные программы прекрасно справляются со своими функциями до тех пор, пока число пользователей не слишком велико. Проблема в том, что любые операции, связанные с базой данных, выполняются на каждом клиентском компьютере. Например, если программе потребуется список всех клиентов по фамилии Смит, вся информация (индексы и записи с данными), необходимая для удовлетворения этого запроса к базе данных, должна быть передана по сети. Некоторые сложные запросы сопряжены c обработкой значительных объемов данных, возможно даже всей базы целиком. На техническом уровне достаточно сложно реализовать управление независимыми процессорами баз данных с целью исключить конфликты при одновременном обращении двух клиентов к одной и той же записи или их попытках изменить ее. Это называется проблемой блокировки записей.

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

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

Двухзвенные приложения программировать немного сложнее, чем однозвенные, правда, интегрированные среды большинства инструментальных пакетов оснащены множеством функций, облегчающих решение этой задачи. Подобные инструменты настолько совершенны, что разница во времени, необходимом для разработки двух- и однозвенных программ, почти неощутима. Единственный негативный момент -- стоимость такого решения. Как правило, инструментальные пакеты содержат процессоры баз данных, вполне подходящие для однозвенных схем (такие, как процессор Jet в Access и Visual Basic), тогда как для двухзвенных программ требуются отдельные СУБД, например Oracle, IBM DB2, Sybase или Microsoft SQL Server.

Двухъярусные архитектуры появились после возникновения ПЭВМ, на которых можно не только отображать информацию, но и обрабатывать ее, снимая часть нагрузки с других слоев. Презентационные модули стали независимыми, такая архитектура называются архитектурой "клиент/сервер".

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

Лучший пример тонкого клиента -- Web-браузер, настолько универсальный, что способен подключаться к абсолютно разным прикладным программам, о которых "не знает" ничего, и тем не менее обеспечивать приемлемый интерфейс пользователя. Вся концепция сетевого компьютера строится на идее создания дешевого небольшого устройства, на котором будет работать Web-браузер.

Тонкого" клиента проще переносить из одного окружения в другое. "Толстые" клиенты требуют больше ресурсов. Если сервер имеет хорошо определенный, стабильный прикладной программный интерфейс, для него можно разработать все виды клиентов и производить модернизацию сервера без изменения в клиентах. Преимущества перед одноярусными системами: отсутствие переключения контекста, переносимость. Проблемы: ограниченность связи со многими клиентами одновременно, которая требует переключать контекст, трудность работы с разными серверами, когда клиент начинает зависеть от нескольких систем, а изменения в него надо вносить при изменениях любого из серверов. За интеграцию начинает отвечать клиент, который должен комбинировать данные от нескольких серверов, отрабатывать все исключительные ситуации от всех своих серверов, координировать доступ ко всем серверам и т. д.

3. Трехъярусные и многоярусные архитектуры распределенных информационных систем

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

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

В трехзвенных программах клиент-сервер презентационный слой обычно "не имеет представления" о структуре базы данных. Вместо этого он взаимодействует с сервером приложения в соответствии со стратегией обмена заранее определенными сообщениями.

Пример: Чтобы лучше понять этот подход, вспомним про Web. Ведь браузер пользователя ничего "не знает" о структуре базы данных, скажем, на узле Amazon.com, тем не менее этот самый пользователь обращается к ней при заказе книги. Благодарить за такую возможность надо четко определенные протоколы Интернета, которые позволяют клиенту (браузеру) обмениваться информацией с сервером приложения (Web-узлом). Книгу можно заказать с любого ПК, а не только со своего собственного и с помощью любого браузера, имеющего средства для работы с формами.

Составлять трезвенные программы гораздо сложнее, чем двухзвенные. Хуже всего то, что интегрированные среды разработки инструментальных пакетов не обзавелись еще средствами, необходимыми для разработки трехзвенной модели. Поэтому подготовка трехзвенных систем не обходится без больших объемов программирования вручную. Еще одна трудность вызвана тем, что трехзвенные приложения -- понятие более отвлеченное, чем их двухзвенные собратья. Заметим, что постепенно появляются новые версии инструментальных пакетов, которые, если верить рекламе, позволяют составлять трех- и многозвенные программы, но пока они не отличаются зрелостью.

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

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

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

Разработчикам трехзвенных программ с архитектурой клиент--сервер обычно приходится решать, какую часть бизнес-логики следует перенести на отдельный сервер приложений. Хороший пример -- проверка вводимых данных. Большинство пользователей предпочитают немедленную реакцию системы на ошибочно введенные данные. Если сервер приложения размещен на отдельном компьютере, вероятно, сообщение о некорректности введенного значения, подготовленное средствами презентационного слоя на ПК клиента, будет появляться не сразу. Чтобы не наносить ущерба производительности, правила проверки часто размещают вместе с презентационным слоем на клиентской машине.

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

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

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

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

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

Внутри системы могут быть дополнительные клиенты, обслуживаемые, как и внешние клиенты, либо через сетевой сервер, либо непосредственным доступом к прикладной логике, реализованной в промежуточном слое. Часто прикладная логика реализуется на кластерах. Внутри системы могут сосуществовать несколько промежуточных платформ, каждая для своего приложения и своей функциональности. За ними могут быть простые файловые серверы или базы данных, работающие на большой ЭВМ, и состоящие из двух-, трех- и многоярусных систем.

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

4. Синхронное и асинхронное, блокирующее и неблокирующее взаимодействие

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

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

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

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

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

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

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

* Большая часть функциональности брокеров объектов уже была реализована в транзакционных мониторах. Однако возникла необходимость перевести Транзакционные мониторы, основанные на процедурных языках, на объектно-ориентированные языки программирования. Эти факторы привели к сближению транзакционных мониторов и брокеров объектов, новые системы стали называться мониторами объектов.

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

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

5. Принципы реализации удаленного вызова процедур. Основные проблемы реализации

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

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

Второй шаг - трансляция созданного описания и создание:

(1) клиентского переходника с программами поиска сервера, форматирования данных (маршалинг - упаковка данных в формат сообщения, сериализация - преобразование сообщения в последовательность байтов), взаимодействия с сервером, передачи параметров и получения ответа;

(2) серверного переходника, реализующего серверную часть вызова и состоящего из программ получения запроса от клиента, форматирования данных (десериализация и демаршалинг), вызова реальной процедуры, реализованной на сервере, возврата результатов клиенту;

(3) программных шаблонов и ссылок (например, файлов-заголовков *.h).

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

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

Недостаток: тесная связь клиента и сервера (если сервер не работает, то клиент тоже). Смена адреса сервера приводит к перекомпиляции клиента с новым переходником с новым адресом. Использование дополнительных серверов для повышения производительности невозможно. При динамическом связывании создается специализированная служба, ответственная за поиск серверов. Динамическое связывание повышает гибкость системы за счет ее производительности. Клиент не знает, является ли он статическим или динамическим.

Вывод: при RPC клиент и сервер должны следовать согласованным протоколам, интерпретация форматов должна быть однозначной. В протоколе надо также согласовывать транспортный протокол.

Стандартный вызов RPC - полная блокировка клиента до получения ответа от сервера. Если ответ не нужен, то сервер замирает навсегда. В таких случаях используют асинхронные вызовы. Сервер сразу отвечает клиенту от своем запуске, а потом работают оба. Блокировка ответа снимается.

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

Список литературы

1. Попов И.Г., Мамонов С.Г. Информационные системы. М.: Инфра, 2007.

2. Абросимов А.Г. Бородинова М.А. Теория экономических информационных систем. Учебное пособие - Самара. Изд-во Самарск.гос. экон. акад., 2007.

3. Информационные системы. Учебник /Петров В.Н. - СПб.: Питер, 2008.

4. Информационное обеспечение систем управления. Учебное пособие/Голенищев Э.П., Клименко И.В. - Ростов н/Д: Феникс, 2009.

5. Интеллектуальные информационные системы в экономике. Учебное пособие/Тельнов Ю.Ф. Издание третье, расширенное и доработанное. Серия «Экономика и бизнес». - Москва.: СИНТЕГ, 2009.

Размещено на Allbest.ru