Добавлен: 17.05.2023
Просмотров: 79
Скачиваний: 4
Взаимодействие между промежуточным сервером и сервером баз данных также соответствует модели клиент-сервер. Таким образом, промежуточная система функционирует одновременно и как клиент, и как сервер.
INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMAT INCLUDEPICTURE "/Volumes/HD2/mfpu/%D0%BA%D1%83%D1%80%D1%81%D0%BE%D0%B2%D1%8B%D0%B5/User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMATINET INCLUDEPICTURE "../../../%25D0%25BA%25D1%2583%25D1%2580%25D1%2581%25D0%25BE%25D0%25B2%25D1%258B%25D0%25B5/User/AppData/Local/Temp/FineReader10/media/image7.jpeg" \* MERGEFORMAT 
Рис. 5 - Трехзвенная архитектура клиент-сервер
1.8. Промежуточное программное обеспечение
Процессы разработки и развертывания программных продуктов, относящихся к архитектуре клиент-сервер, значительно опередили процессы стандартизации всех аспектов распределенных вычислений от физического до прикладного уровня. Отсутствие стандартов затрудняет реализацию интегрированной конфигурации, состоящей из устройств различных производителей. Поскольку основные достоинства архитектуры клиент-сервер связаны с ее модульностью, а также с возможностью объединять различные платформы и приложения, необходимо решить вопросы совместной работы этих платформ и приложений.
Чтобы добиться максимальной эффективности применения архитектуры клиент- сервер, разработчики должны обладать набором инструментальных средств, предоставляющих единообразные средства и обеспечивающие единый стиль доступа к системным ресурсам на всех платформах. Это позволит программистам создавать приложения, которые не только одинаково выглядят на различных персональных компьютерах и рабочих станциях, но и используют один и тот же метод доступа к данным, независимо от их расположения.5
Наиболее общий подход к удовлетворению этих требований заключается в использовании стандартных интерфейсов и протоколов между приложением, с одной стороны, и коммуникационным программным обеспечением и операционной системой, с другой. Эти стандартизованные интерфейсы и протоколы получили название промежуточного программного обеспечения. Наличие стандартных программных интерфейсов облегчает развертывание одного и того же приложения на серверах и рабочих станциях разных типов. Это, очевидно, является достоинством не только для потребителя, но и для производителя. Это связано с тем, что потребители приобретают приложения, а не серверы. Потребители только выбирают серверные продукты, на которых работают нужные им приложения. Стандартизованные протоколы необходимы для взаимодействия различных серверных интерфейсов с клиентами.
Существуют разные пакеты промежуточного программного обеспечения от очень простых до очень сложных. Всех их объединяет способность скрывать от пользователя сложности и несоответствия различных сетевых протоколов и операционных систем. Производители клиентов и серверов, как правило, предлагают на выбор ряд популярных пакетов промежуточного программного обеспечения. Таким образом, пользователь может выбрать определенную стратегию развертывания промежуточного программного обеспечения, а затем заняться приобретением оборудования от разных производителей, поддерживающих данную стратегию.8
Архитектура промежуточного программного обеспечения
На рис. 6 демонстрируется возможное применение промежуточного программного обеспечения в архитектуре клиент-сервер. Точная роль промежуточного программного обеспечения зависит от вычислительной модели клиент-сервер. Как было показано на рис. 6, существует несколько классов приложений клиент-сервер, зависящих от способа разделения функций приложения.
INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMAT INCLUDEPICTURE "/Volumes/HD2/mfpu/%D0%BA%D1%83%D1%80%D1%81%D0%BE%D0%B2%D1%8B%D0%B5/User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMATINET INCLUDEPICTURE "../../../%25D0%25BA%25D1%2583%25D1%2580%25D1%2581%25D0%25BE%25D0%25B2%25D1%258B%25D0%25B5/User/AppData/Local/Temp/FineReader10/media/image8.jpeg" \* MERGEFORMAT 
Рис. 6 - Роль промежуточного программного обеспечения в архитектуре клиент-сервер
Обратите внимание, что промежуточное программное обеспечение состоит из двух компонентов — клиентского и серверного. Основное назначение промежуточного программного обеспечения заключается в обеспечении доступа приложения или пользователя к различным услугам, предоставляемым на серверах, причем так, чтобы не беспокоиться о различиях серверов. Стандартным средством доступа к реляционной базе данных как для локального, так и для удаленного пользователя или приложения является язык структурированных запросов (SQL). Однако многие производители реляционных баз данных, хотя и поддерживают язык SQL, добавили к нему свои собственные расширения. Это, с одной стороны, позволяет производителям различать свою продукцию, но, с другойстороны, приводит к несовместимости.
Для примера рассмотрим распределенную систему, обслуживающую, помимо прочего, отдел кадров. Основные сведения о сотрудниках, такие как имена, адреса и т. д., могли бы храниться в базе данных от Gupta, тогда как информация о зарплате — в базе данных от Oracle. Когда пользователь в отделе кадров запрашивает доступ к определенным записям, он не должен думать, в которой из баз данных хранятся требуемые ему записи и кто является производителем этой базы данных. Единообразный доступ к этим системам должно предоставлять промежуточное программное обеспечение.
INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMAT INCLUDEPICTURE "/Volumes/HD2/mfpu/%D0%BA%D1%83%D1%80%D1%81%D0%BE%D0%B2%D1%8B%D0%B5/User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMATINET INCLUDEPICTURE "../../../%25D0%25BA%25D1%2583%25D1%2580%25D1%2581%25D0%25BE%25D0%25B2%25D1%258B%25D0%25B5/User/AppData/Local/Temp/FineReader10/media/image9.jpeg" \* MERGEFORMAT 
Рис. 7 - Промежуточное программное обеспечение с точки зрения логики
На роль промежуточного программного обеспечения полезно взглянуть с точки зрения логики, а не реализации (рис. 7). Вся распределенная система может рассматриваться как набор приложений и ресурсов, доступных пользователю. Пользователям не нужно беспокоиться о расположении данных или приложений. Все приложения работают поверх унифицированного прикладного программного интерфейса (ApplicationProgrammingInterface, API). За маршрутизацию запросов клиента к соответствующему серверу отвечает промежуточное программное обеспечение, присутствующее на всех клиентских и серверных платформах.
Распределенную передачу сообщений, реализующую функциональность архитектуры клиент-сервер, иллюстрирует на рис. 8, а. Клиентский процесс запрашивает некую услугу (например, прочитать или распечатать на принтере файл). Для этого он посылает сообщение с запросом данной услуги серверному процессу. Серверный процесс принимает сообщение, обрабатывает запрос и посылает ответное сообщение. В простейшем случае требуются только две функции: Send(отправить) и Receive(принять). Функции Sendна входе необходимо указать получателя, а также содержимое сообщения. Функции Receiveнужно указать, от кого ожидается сообщение (включая вариант «все») и адрес буфера, в который следует поместить принятое сообщение.
Рис. 8 - Механизмы реализации промежуточного программного обеспечения
На рис. 9 показана схема возможной реализации механизма передачи сообщений. Процессы пользуются услугами модуля передачи сообщений. Запросы на эти услуги могут иметь вид примитивов и параметров. Примитив соответствует исполняемой функции, в параметры используются для передачи данных и контроля над информацией.5 Конкретная форма примитивов зависит от программного обеспечения передачи сообщений. Это может быть вызов процедуры или передача сообщения процессу операционной системы.
INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMAT INCLUDEPICTURE "/Volumes/HD2/mfpu/%D0%BA%D1%83%D1%80%D1%81%D0%BE%D0%B2%D1%8B%D0%B5/User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMATINET INCLUDEPICTURE "../../../%25D0%25BA%25D1%2583%25D1%2580%25D1%2581%25D0%25BE%25D0%25B2%25D1%258B%25D0%25B5/User/AppData/Local/Temp/FineReader10/media/image11.jpeg" \* MERGEFORMAT 
Рис. 9 - Базовые примитивы передачи сообщений
Примитив Sendиспользуется процессом, желающим отправить сообщение. Входными параметрами этого примитива являются идентификатор получающего процесса и содержимое сообщения. Модуль передачи сообщений формирует блок данных, включающий эти два элемента. Этот блок данных посылается на машину, на которой работает получающий процесс, при помощи каких-либо сетевых протоколов, например, TCP/IP. Когда адресат получает блок данных, этот блок направляется модулю передачи сообщений. Этот модуль исследует поле идентификатора процесса и сохраняет сообщениев буфере этого процесса.
В этом сценарии получающий процесс должен объявить о своем желании получать сообщения, выделить буфер для сообщений и информировать модуль передачи сообщений при помощи примитива Receive. Альтернативный метод не требует подобного объявления. Просто когда модуль передачи сообщений получает сообщение, он сигнализирует процессу, которому оно адресовано, а затем помещает сообщение в общий буфер.
Существует несколько вариантов реализации механизма распределенной передачи сообщений, о которых будет говориться далее.
Надежная передача сообщений
Надежной называется такая система передачи сообщений, которая гарантирует доставку сообщения, если такая доставка возможна. В подобной системе используется надежный транспортный протокол или сходная логика, а также должны поддерживаться контроль ошибок, квитирование, повторная передача и восстановление порядка следования сообщений. Поскольку доставка гарантирована, нет необходимости уведомлять передающий процесс о доставке сообщения. Тем не менее может быть полезно возвращать передающему процессу подтверждения, чтобы уведомить его о том, что сообщение доставлено. В любом случае, если системе не удается доставить сообщение (например, из-за неисправности сети или выходе из строя получателя), передающий процесс уведомляется о неудаче. Другую крайность представляет собой система передачи сообщений, которая просто посылает сообщения в компьютерную сеть, но не сообщает ни об успехе, ни о неудаче. Эта альтернатива позволяет значительно упростить систему передачи сообщений и накладные расходы на обработку и взаимодействие. Если приложению требуется подтверждение доставки сообщения, это может быть реализовано на прикладном уровне.
Синхронные и асинхронные системы передачи сообщений
При обращении к асинхронному (также называемому неблокирующим) примитиву, процесс не приостанавливается. Таким образом, после того как процесс вызывает примитив Send, операционная система возвращает процессу управление сразу после установки сообщения в очередь на передачу или после создания копии сообщения. Когда сообщение передано или скопировано в безопасное место для последующей передачи, передающий процесс прерывается и, таким образом, информируется о том, что буфером сообщения можно пользоваться снова. Если копии сообщения не создается, то любые изменения сообщения, производимые передающим процессом уже после обращения к примитиву Send, но до отправки сообщения, являются рискованными. Аналогично, после обращения к асинхронному примитиву Receiveпроцесс продолжает работу. Когда сообщение прибывает, процесс информируется об этом событии путем прерывания или периодического опроса.
Асинхронные примитивы обеспечивают эффективное и гибкое обращение процессов к системе передачи сообщений. Недостаток этого подхода заключается в том, что программы, использующие подобные примитивы, трудно тестировать и отлаживать. События, которые зависят от времени и которые невозможно воспроизвести, могут стать источником трудноразрешимых проблем.4
Альтернатива заключается в использовании синхронных или, как их еще называют, блокирующих примитивов. При вызове синхронного примитива Sendуправление не возвращается передающему процессу до тех пор, пока сообщение не будет передано (ненадежное обслуживание), или до тех пор, пока не будет получено подтверждение о доставке сообщения (надежное обслуживание). Блокирующий примитив Receiveне возвратит управление, пока сообщение не окажется в выделенном для него буфере.
Базовые сведения клиент-сервер
Уделенный вызов процедуры (RemoteProcedureCall, RPC) представляет собой вариант базовой модели передачи сообщения. Сегодня уделенные вызовы процедур являются общим и широко применяемым методом инкапсуляции взаимодействия в распределенной системе. Суть этой техники состоит в том, чтобы позволить программам на разных машинах взаимодействовать друг с другом путем простого вызова процедур, как если бы они работали на одной машине. Таким образом, механизм вызова процедур используется для доступа к услугам, предлагаемым удаленной машиной. Популярность этого подхода связана со следующими преимуществами.