20434

Программное обеспечение промежуточного уровня

Доклад

Информатика, кибернетика и программирование

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

Русский

2013-07-25

110.5 KB

1 чел.

9

1.4.3. Программное обеспечение промежуточного уровня

Ни распределенные, ни сетевые операционные системы не соответствуют нашему определению распределенных систем, данному в разделе 1.1. Распределенные операционные системы не предназначены для управления набором независимых компьютеров, а сетевые операционные системы не дают представления одной согласованной системы. На ум приходит вопрос: а возможно ли вообще разработать распределенную систему, которая объединяла бы в себе преимущества двух «миров» — масштабируемость и открытость сетевых операционных систем и прозрачность и относительную простоту в использовании распределенных операционных систем? Решение было найдено в виде дополнительного уровня программного обеспечения, который в сетевых операционных системах позволяет более или менее скрыть от пользователя разнородность набора аппаратных платформ и повысить прозрачность распределения. Многие современные распределенные системы построены в расчете на этот дополнительный уровень, который получил название программного обеспечения промежуточного уровня. В этом пункте мы кратко рассмотрим, как устроено программное обеспечение промежуточного уровня, чтобы понять его особенности.

Позиционирование программного обеспечения промежуточного уровня

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

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

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

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

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

Модели промежуточного уровня

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

Подобный же подход, но менее строгий, чем в Plan 9, применяется в программном обеспечении промежуточного уровня, построенном по принципу распределенной файловой системы (distributed file system). Во многих случаях это программное обеспечение всего на один шаг ушло от сетевых операционных систем в том смысле, что прозрачность распределения поддерживается только для стандартных файлов (то есть файлов, предназначенных только для хранения данных). Процессы, например, часто должны запускаться исключительно на определенных машинах. Программное обеспечение промежуточного уровня, основанное на модели распределенной файловой системы, оказалось достаточно легко масштабируемым, что способствовало его популярности.

Другая важная ранняя модель программного обеспечения промежуточного уровня основана на удаленных вызовах процедур (Remote Procedure Calls, RFC). В этой модели акцент делается на сокрытии сетевого обмена за счет того, что процессу разрешается вызывать процедуры, реализация которых находится на удаленной машине. При вызове такой процедуры параметры прозрачно передаются на удаленную машину, где, собственно, и выполняется процедура, после чего результат выполнения возвращается в точку вызова процедуры. За исключением, вероятно, некоторой потери производительности, все это выглядит как локальное исполнение вызванной процедуры: вызывающий процесс не уведомляется об имевшем место факте сетевого обмена. Мы вернемся к вызовам удаленных процедур в следующей главе.

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

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

Как модели могут упростить использование сетевых систем, вероятно, наилучшим образом видно на примере World Wide Web. Успех среды Web в основном определяется тем, что она построена на базе потрясающе простой, но высокоэффективной модели распределенных документов (distributed documents). В модели, принятой в Web, информация организована в виде документов, каждый из которых размещен на машине, расположение которой абсолютно прозрачно. Документы содержат ссылки, связывающие текущий документ с другими. Если следовать по ссылке, то документ, с которым связана эта ссылка, будет извлечен из места его хранения и выведен на экран пользователя. Концепция документа не ограничивается исключительно текстовой информацией. Например, в Web поддерживаются аудио и видеодокументы, а также различные виды документов на основе интерактивной графики.

Службы промежуточного уровня

Существует некоторое количество стандартных для систем промежуточного уровня служб. Все программное обеспечение промежуточного уровня неизменно должно тем или иным образом реализовывать прозрачность доступа путем предоставления высокоуровневых средств связи (communication facilities), скрывающих низкоуровневую пересылку сообщений по компьютерной сети. Интерфейс программирования транспортного уровня, предоставляемый сетевой операционной системой, полностью заменяется другими средствами. Способ, которым поддерживается связь, в значительной степени зависит от модели распределения, предлагаемой программным обеспечением промежуточного уровня пользователям и приложениям. Мы уже упоминали удаленный вызов процедур и обращение к распределенным объектам. Кроме того, многие системы промежуточного уровня предоставляют средства для прозрачного доступа к удаленным данным, такие как распределенные файловые системы или распределенные базы данных. Прозрачная доставка документов, реализуемая в Web, — это еще один пример коммуникаций высокого уровня (однонаправленных).

Важная служба, общая для всех систем промежуточного уровня, — это именование (naming). Службы именования сравнимы с телефонными книгами или справочниками типа «Желтых страниц». Они позволяют совместно использовать и искать сущности (как в каталогах). Хотя присвоение имен на первый взгляд кажется простым делом, при масштабировании возникают серьезные трудности. Проблема состоит в том, что для эффективного поиска имени в большой системе местоположение разыскиваемой сущности должно считаться фиксированным.Такое допущение, в частности, принято в среде World Wide Web, в которой любой документ поименован посредством URL. URL содержит имя сервера, на котором находится документ с данным URL адресом. Таким образом, если документ переносится на другой сервер, его URL перестает работать.

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

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

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

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

Промежуточный уровень и открытость

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

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

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

Еще один пример. Для гарантии совместной работы различных реализаций необходимо, чтобы к сущностям разных систем можно было одинаково обращаться. Если к сущностям в одной системе обращение идет через URL, а в другой системе — через сетевой адрес, понятно, что перекрестные обращения приведут к проблемам. В подобных случаях определения интерфейсов должны точно предписывать вид ссылок.

Сравнение систем

Краткое сравнение распределенных операционных систем, сетевых операционных систем и распределенных систем промежуточного уровня приводится в табл. 1.5.

Таблица 1.5. Сравнение распределенных операционных систем, сетевых операционных систем и распределенных систем промежуточного уровня

 
Характеристика


Распределенная операционная
система

Сетевая операционная система

Распределенная система промежуточ-ного уровня

 

мульти- процессорная

мульти-компьютерная

 

 

Степень прозрачности

Очень высокая

Высокая

Низкая

Высокая

Идентичность операционной системы на всех узлах

Поддерживается

Поддерживается

Не поддерживается

Поддерживается

Число копий ОС

1

N

N

N

Коммуникации на основе

Совместно памяти используемой

Сообщений

Файлов

В зависимости от модели

Управление ресурсами

Глобальное централизован ное

Глобальное распределенное

Отдельно на узле

Отдельно на узле

Масштабируемость

Отсутствует

Умеренная

Да

Различная

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

37393. Расчет вала с зубчатыми колесами 1.27 MB
  Необходимо: подобрать диаметр вала d из условия статической прочности. В опасном сечении вала построить эпюры нормальных и касательных напряжений и показать напряжённое состояние тела в опасной точке; произвести расчёт вала на жёсткость по линейным перемещениям в местах установки колёс и по угловым перемещениям в опорах. Уточнить диаметр вала; выполнить проверочный расчёт вала на усталостную прочность в опасном сечении. Проектировочный расчёт вала на статическую прочность [2] 2.
37394. Восстановление документов компании ОАО «ИКАР» 40.64 KB
  Посчитать убытки от не заключения или несвоевременного заключения договора. Работа должна содержать: Актуальность проблемы практическую значимость решения проблемы объект предмет исследования цели и задачи работы и состоять из 4 глав Оглавление Введение6 Договоры Письма Предложениямероприятия 8 Расчеты10...
37395. Технологический проект овощного цеха общедоступной столовой на 78 мест 1.35 MB
  Расчёт количества блюд. Расчет количества блюд в ассортимент12 3. Расчет реализации блюд по часам работы зала19 3. Столовая предназначена для обслуживания горячими и холодными напитками кисломолочными продуктами мучными кондитерскими изделиями холодными и горячими блюдами несложного приготовления сладкими блюдами.
37396. Экономическая эффективность совершенствование организации перевозок контейнеров на маршруте Симферополь-Джанкой 9.22 MB
  Сдельная заработная плата водителя Где коэффициент учитывающий класс перевозимого груза грн. Учитывающий размер премии грн. грн. Доплата за руководство бригадой Где размер доплаты за руководство бригадой грн.
37399. Моделирование движения заряженных частиц в электрических и магнитных полях 690 KB
  В дерева dd physics выберите Mthemtics Mthemticl Prticle Trcing pt. В дереве выберите Preset Studies Time Dependent. Построение геометрической модели Задание области в корой движутся частицы В окне Model Builder щелкните ПКМ Model 1 Geometry 1 и выберите Cylinder Перейдите к окну Settings для Cylinder. Выберите размер и форму сечения.
37400. Габаритний розрахунок монокуляра з вибором оптичної схеми об’єктива і окуляра 1.43 MB
  Наявність в трьох лінзових обєктивах великої кількості вільних параметрів марки стекол радіуси товщини і повітряні проміжки дозволяє істотно поліпшити їх абераційних корекцію в порівнянні з двох лінзовими. Окуляр Гюйгенса В цих окулярах компонентами є плосковипуклі або випуклоплоскі лінзи виготовлені із оптичного скла однієї марки. Показник заломлення Марка скла 4878 125 16475 К8 2599 29265 25 15163 ТФ1 Вибраний об’єктив має фокусну відстань f ’об = 100 мм. Показник заломлення Марка скла 14634...
37401. Расчет электромагнитных переходных процессов. Методические указания к курсовому и дипломному проектированию 16.74 MB
  Составим схему замещения прямой последовательности Определим параметры схемы замещения прямой последовательности: Система Линия 1 Линия 2 Трансформатор Трансформатор Т1 Реактор Автотрансформатор Нагрузка 1 Нагрузка 2 Асинхронный двигатель Генератор 1 Генератор 2 Все параметры элемента генератор 2 точно такие же как и у элемента генератор 1 Найдем и для этого свернем схему Составим схему замещения обратной последовательности Определим параметры схемы замещения обратной...