Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Лекции по общей теории перевода

Итоги

Варианты архитектуры клиент-сервер

Разделение приложений по уровням

 

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

уровень пользовательского интерфейса;

уровень обработки;

уровень данных.

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

 

Уровень пользовательского интерфейса

 

Уровень пользовательского интерфейса обычно реализуется на клиентах. Этот уровень содержит программы, посредством которых пользователь может взаимодействовать с приложением. Сложность программ, входящих в пользовательский интерфейс, весьма различна. Простейший вариант программы пользовательского интерфейса не содержит ничего, кроме символьного (не графического) дисплея. Такие интерфейсы обычно используются при работе с мэйнфреймами. В том случае, когда мэйнфрейм контролирует все взаимодействия, включая работу с клавиатурой и монитором, мы вряд ли можем говорить о модели клиент-сервер. Однако во многих случаях терминалы пользователей производят некоторую локальную обработку, осуществляя, например, эхо-печать вводимых строк или предоставляя интерфейс форм, в котором можно отредактировать введенные данные до их пересылки на главный компьютер. В наше время даже в среде мэйнфреймов наблюдаются более совершенные пользовательские интерфейсы. Обычно на клиентских машинах имеется как минимум графический дисплей, на котором можно задействовать всплывающие или выпадающие меню и множество управляющих элементов, доступных для мыши или клавиатуры. Типичные примеры таких интерфейсов — надстройка X-Windows, используемая во многих UNIX-системах, и более ранние интерфейсы, разработанные для персональных компьютеров, работающих под управлением MSDOS и Apple Macintosh.

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

 

Уровень обработки

Многие приложения модели клиент-сервер построены как бы из трех различных частей: части, которая занимается взаимодействием с пользователем, части, которая отвечает за работу с базой данных или файловой системой, и средней части, реализующей основную функциональность приложения. Эта средняя часть логически располагается на уровне обработки. В противоположность пользовательским интерфейсам или базам данных на уровне обработки трудно выделить общие закономерности. Однако мы приведем несколько примеров для разъяснения вопросов, связанных с этим уровнем. В качестве первого примера рассмотрим поисковую машину в Интернете. Если отбросить все анимированные баннеры, картинки и прочие оконные украшательства, пользовательский интерфейс поисковой машины очень прост: пользователь вводит строку, состоящую из ключевых слов, и получает список заголовков web-страниц. Результат формируется из гигантской базы просмотренных и проиндексированных web-страниц. Ядром поисковой машины является программа, трансформирующая введенную пользователем строку в один или несколько запросов к базе данных. Затем она помещает результаты запроса в список и преобразует этот список в набор HTML-страниц. В рамках модели клиент- сервер часть, которая отвечает за выборку информации, обычно находится на уровне обработки. Эта структура показана на рис. 1.19.

 

Рис. 1.19. Обобщенная организация трехуровневой поисковой машины для Интернета

 

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

 

Уровень данных

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

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

 

 

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

Клиентские машины, на которых имеются программы, реализующие только пользовательский интерфейс или его часть.

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

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

 

Многозвенные архитектуры

Один из подходов к организации клиентов и серверов — это распределение программ, находящихся на уровне приложений, описанном в предыдущем пункте, по различным машинам, как показано на рис. 1.20. В качестве первого шага мы рассмотрим разделение на два типа машин: на клиенты и на серверы, что приведет нас к физически двухзвенной архитектуре (physically two-tiered architecture). Один из возможных вариантов организации — поместить на клиентскую сторону только терминальную часть пользовательского интерфейса, как показано на рис. 1.20, а, позволив приложению удаленно контролировать представление данных. Альтернативой этому подходу будет передача клиенту всей работы с пользовательским интерфейсом (рис. 1.20, б). В обоих случаях мы отделяем от приложения графический внешний интерфейс, связанный с остальной частью приложения (находящейся на сервере) посредством специфичного для данного приложения протокола. В подобной модели внешний интерфейс делает только то, что необходимо для предоставления рн1терфейса приложения.

 

Рис. 1.20. Альтернативные формы организации архитектуры клиент-сервер

 

Продолжим линию наших рассуждений. Мы можем перенести во внешний интерфейс часть нашего приложения, как показано на рис. 1.20, в. Примером может быть вариант, когда приложение создает форму непосредственно перед ее заполнением. Внешний интерфейс затем проверяет правильность и полноту заполнения формы и при необходимости взаимодействует с пользователем. Другим примером организации системы по образцу, представленному на рис. 1.20, в, может служить текстовый процессор, в котором базовые функции редактирования осуществляются на стороне клиента с локально кэшируемыми или находящимися в памяти данными, а специальная обработка, такая как проверка орфографии или грамматики, выполняется на стороне сервера. Во многих системах клиент-сервер популярна организация, представленная на рис. 1.20, г и Э. Эти типы организации применяются в том случае, когда клиентская машина — персональный компьютер или рабочая станция — соединена сетью с распределенной файловой системой или базой данных. Большая часть приложения работает на клиентской машине, а все операции с файлами или базой данных передаются на сервер. Рисунок 1.20, д отражает ситуацию, когда часть данных содержится на локальном диске клиента. Так, например, при работе в Интернете клиент может постепенно создать на локальном диске огромный кэш наиболее часто посещаемых web-страниц. Рассматривая только клиенты и серверы, мы упускаем тот момент, что серверу иногда может понадобиться работать в качестве клиента. Такая ситуация, отраженная на рис. 1.21, приводит нас к физически трехзвенной архитектуре (physically three-tiered architecture). В подобной архитектуре программы, составляющие часть уровня обработки, выносятся на отдельный сервер, но дополнительно могут частично находиться и на машинах клиентов и серверов. Типичный пример трехзвенной архитектуры — обработка транзакций. В этом случае отдельный процесс — монитор транзакций — координирует все транзакции, возможно, на нескольких серверах данных. Мы вернемся к обработке транзакций в следующих главах.

 

Рис. 1.21. Пример сервера, действующего как клиент

 

Современные варианты архитектуры

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

Однако вертикальное распределение — это лишь один из возможных способов организации приложений клиент-сервер, причем во многих случаях наименее интересный. В современных архитектурах распределение на клиенты и серверы происходит способом, известным как горизонтальное распределение (horizontal distribution). При таком типе распределения клиент или сервер может содержать физически разделенные части логически однородного модуля, причем работа с каждой из частей может происходить независимо. Это делается для выравнивания загрузки. В качестве распространенного примера горизонтального распределения рассмотрим web-сервер, peплициpoвaнный на несколько машин локальной сети, как показано на рис. 1.22. На каждом из серверов содержится один и тот же набор web-страниц, и всякий раз, когда одна из web-страниц обновляется, ее копии незамедлительно рассылаются на все серверы. Сервер, которому будет передан приходящий запрос, выбирается по правилу «карусели» (round-robin). Эта форма горизонтального распределения весьма успешно используется для выравнивания нагрузки на серверы популярных web-сайтов. Таким же образом, хотя и менее очевидно, могут быть распределены и клиенты. Для несложного приложения, предназначенного для коллективной работы, мы можем не иметь сервера вообще. В этом случае мы обычно говорим об одноранговом распределении (peer-to-peer distribution). Подобное происходит, например, если пользователь хочет связаться с другим пользователем. Оба они должны запустить одно и то же приложение, чтобы начать сеанс. Третий клиент может общаться с одним из них или обоими, для чего ему нужно запустить то же самое приложение.

 

 

Рис. 1.22. Пример горизонтального распределения web-службы

 

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

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

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

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

 

Вопросы и задания

Какова роль программного обеспечения промежуточного уровня в распределенных системах?

Объясните, что такое прозрачность (распределения) и приведите примеры различных видов прозрачности.

Почему иногда так трудно скрыть наличие в распределенной системе сбоя и восстановление после него?

Почему реализация максимально возможной степени прозрачности — это не всегда хорошо?

Что такое открытая распределенная система и какие преимущества дает открытость?

Опишите точно, что такое масштабируемая система.

Масштабируемости можно добиться, используя различные методики. Что это за методики?

Чем мультипроцессорная система отличается от мультикомпьютерной?

Мультикомпьютерная система с 256 процессорами организована в виде решетки 16x16. Какая в такой системе может быть максимальная задержка(в хопах)?

Рассмотрим 256-процессорный гиперкуб. Какая максимальная задержка может наблюдаться в нем (снова в хопах)?

В чем состоит разница между распределенными и сетевыми операционными системами?

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

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

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

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

Экспериментальный файловый сервер 3/4 времени работает, а 1/4 времени «лежит» по причине ошибок. Сколько реплик этого сервера должно быть сделано, чтобы его доступность составляла хотя бы 99 %?

Что такое трехзвенная архитектура клиент-сервер?

В чем состоит разница между горизонтальным и вертикальным распределениями?

Рассмотрим цепочку процессов Р1, Р2,..., Рn, которая реализована в многозвенной архитектуре клиент-сервер. Процесс Pi является клиентом процесса Pi+1, возвращая, в свою очередь, результат процессу Pi-1 только после того, как сам получит результат от процесса Pi+1. Какова будет главная проблема подобной организации, когда мы станем рассматривать производительность запроса-ответа для процесса Р1?

СОДЕРЖАНИЕ

Определение распределенной информационно-вычислительной системы 1

1.1. Определение распределенной системы 2

1.2. Задачи 4

1.2.1. Соединение пользователей с ресурсами 4

1.2.2. Прозрачность 5

1.2.3. Открытость 9

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

1.3. Концепции аппаратных решений 18

1.3.1. Мультипроцессоры 20

1.3.2. Гомогенные мультикомпьютерные системы 23

1.3.3. Гетерогенные мультикомпьютерные системы 25

1.4. Концепции программных решений 26

1.4.1. Распределенные операционные системы 27

1.4.2. Сетевые операционные системы 40

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

1.5. Модель клиент-сервер 51

1.5.1. Клиенты и серверы 51

1.5.2. Разделение приложений по уровням 56

1.5.3. Варианты архитектуры клиент-сервер 60

1.6. Итоги 63

Вопросы и задания 64

СОДЕРЖАНИЕ 66

 

 

 

Рекомендовано

Министерством образования и науки Украины

как учебное пособие для студентов высших учебных заведений

 

 

УДК 802 (072)

JSBN – 966 – 604 – 100 - 6

 

 

Рецензенты:

Ф.Ф. Кейда, доктор филологических наук, профессор;

С.П. Волосевич, кандидат филологических наук, доцент

 

Издание одобрено Министерством образования и науки Украины

 

Рекомендовано к печати Ученым советом Приазовского государственного технического университета

 

Жаркова Е.М. Лекции по общей теории перевода. Учебное пособие. – Мариуполь: изд-во ПГТУ. – 2007. – 328 с.

 

 

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

 

 

«Единственно ложная перспектива – это та, которая полагает себя единственной»

(Хосе Ортега-и-Гассет)

 

«Теория перевода – это уже исторический факт. Наша задача заключается в ее расширении и дальнейшем развитии. Законченные теории имеются вообще в немногих областях знания. Существует, скажем, в химии теория неорганических соединений, однако и она со временем изменяется. Также будет меняться и наша теория перевода, но она возможна»

(Альфред Курелла)

 

<== предыдущая лекция | следующая лекция ==>
Клиенты и серверы | Введение. С тех пор как видный лингвист А.А
Поделиться с друзьями:


Дата добавления: 2014-01-11; Просмотров: 785; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.009 сек.