Архитектура промежуточного программного обеспечения

На рис. 17.8 демонстрируется возможное применение промежуточного программного обеспечения в архитектуре клиент-сервер.

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

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

Рис. 17.8. Роль промежуточного программного обеспечения в архитектуре клиент- сервер

Обратите внимание, что промежуточное программное обеспечение состоит из двух компонентов — клиентского и серверного.

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

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

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

Для примера рассмотрим распределенную систему, обслуживающую, помимо прочего, отдел кадров.

Основные сведения о сотрудниках, такие как имена, адреса и т. д., могли бы храниться в базе данных от Gupta, тогда как информация о зарплате — в базе данных от Oracle.

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

Рис. 17.9. Промежуточное программное обеспечение с точки зрения логики

На роль промежуточного программного обеспечения полезно взглянуть с точки зрения логики, а не реализации (рис. 17.9).

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

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

За маршрутизацию запросов клиента к соответствующему серверу отвечает промежуточное программное обеспечение, присутствующее на всех клиентских и серверных платформах.

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

В этом случае промежуточное программное обеспечение используется для решения проблем несовместимости сетей и операционных систем. Сети DECnet, Novell и TCP/IP соединены магистральной сетью.

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

Рис. 17.11. Механизмы реализации промежуточного программного обеспечения

На рис. 17.12 показана схема возможной реализации механизма передачи сообщений.

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

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

Это может быть вызов процедуры или передача сообщения процессу операционной системы.

Рис. 17.12. Базовые примитивы передачи сообщений

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

Модуль передачи сообщений формирует блок данных, включающий эти два элемента. Этот блок данных посылается на машину, на которой работает получающий процесс, при помощи каких-либо сетевых протоколов, например, TCP/IP. Когда адресат получает блок данных, этот блок направляется модулю передачи сообщений. Этот модуль исследует поле идентификатора процесса и сохраняет сообщение в буфере этого процесса.

В этом сценарии получающий процесс должен объявить о своем желании получать сообщения, выделить буфер для сообщений и информировать модуль передачи сообщений при помощи примитива Receive.

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

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

Надежная передача сообщений Надежной называется такая система передачи сообщений, которая гарантирует доставку сообщения, если такая доставка возможна.

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

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

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

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

⇐ Предыдущая 6 7 8 9 101112 13 14 15 Следующая ⇒