6.4 Промежуточное по доступа к базам данных

Рассмотрим два основных типа промежуточного обеспечения, ориентированного на работу с распределенными данными — это собственное промежуточное обеспечение СУБД и основное промежуточное обеспечение баз данных.

• Собственное промежуточное ПО СУБД — это встроенные механизмы доступа для конкретного сервера баз данных.

• Основное промежуточное ПО баз данных — к этому типу относится, например, интерфейс Open Database Connectivity (ODBC), который позволяет программам «общаться» на разных диалектах SQL через общие интерфейсы.

Собственное промежуточное ПО СУБД. К этому виду относится, в первую очередь, поддержка стандартов языка SQL. Несмотря на то, что SQL является международным стандартом, разработчики СУБД самостоятельно определяют, какие из возможностей SQL они будут поддерживать в своих системах. В результате, конкретная СУБД может, с одной стороны, не поддерживать или поддерживать частично некоторые команды SQL, а с другой — представлять разработчикам приложений нестандартные языковые расширения.

Другим видом собственного middleware являются встроенные средства СУБД, позволяющие выполнять импорт данных из внешних источников (например, из других СУБД или текстовых файлов) и экспортировать данные в сторонние форматы (например, CSV или XML).

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

• ODBC (Open DataBase Connectivity, открытое соединение с БД) — это интерфейс доступа к базам данных, разработанный Microsoft. ODBC представляет возможность обращения к реляционным и нереляционным СУБД в гетерогенной среде через унифицированные вызовы API (рис. 6). Обращения к функциям ODBC транслируются в естественные диалекты многих СУБД с помощью специальных ODBC-драйверов либо напрямую, либо через указание имени источника данных (рис. 7).

Рис. 6. а) Доступ к БД через ODBC; б) Интерфейс ODBC.

• JDBC (Java DataBase Connectivity) — это прикладной программный интерфейс для обращения к базам данных из Java-приложений. Средства JDBC являются платформонезависимыми и выполняются в любой среде под управлением виртуальной машины Java. По сравнению с ODBC этот тип промежуточного ПО баз данных предлагает больше возможностей по интеграции приложений и расширяет сферу использования БД (например, в сторону мобильных приложений). Больше того, спецификация JDBC предусматривает возможность доступа Java-приложений к БД через ODBC с помощью специального средства, т.н. «моста» (ODBC/JDBC-bridge).

• EDA (Event-Driven Architecture, событийно-управляемая архитектура) — это концепция управления корпоративной информационной системой на основе событий, возникающих в бизнес-процессе. Доступ к БД в EDA базируется на использовании централизованного способа обращения к распределенным базам данных. Все запросы клиентов поступают на вход SQL-шлюза, который транслирует SQL-запросы в унифицированный формат и перенаправляет их к серверам БД. Взаимодействие с ними возможно как через набор общих API, так и через ODBC-интерфейс (рис. 8). Использование SQL-шлюза обеспечивает доступ к данным в разнородных многозвенных системах, где множество приложений параллельно обращаются к источникам данных различного формата.

Рис. 8. Принцип доступа к БД в EDA

• DQB (Distributed Query Broker, брокер распределенных запросов) — децентрализованное (в отличие от EDA) решение для доступа к БД на основе ORB. Заглушки-брокеры, размещенные на серверах БД, принимают унифицированные SQL-запросы и транслируют их в диалекты конкретных СУБД (рис. 9).

Рис. 9. Брокер распределенных запросов (DQB)

Стек протоколов TCP/IP давно уже поддерживается на уровне операционных систем, средства RPC также доступны в сетевых ОС едва ли не "по умолчанию". Этот механизм практически не требует от разработчиков и интеграторов каких-либо новых знаний и навыков. Не требуется изучать специфические middleware API: вызов удаленной процедуры ничем не отличается от обращения к локальной подпрограмме, а все процессы преобразования данных и передачи их по сети выполняются клиентской и серверной заглушками. Использование RPC может быть наиболее подходящим решением для систем, где возможные проблемы, связанные с синхронностью протокола RPC, не являются критичными.

Промежуточное ПО обмена сообщениями предлагает бОльшую, по сравнению с RPC, гибкость, так как ни одно из взаимодействующих приложений не блокируется в процессе обмена сообщениями. Такое решение лучше подойдет для автоматизированных систем, компоненты которых слабо связаны, работают в независимом временном режиме и используют разнородную сетевую среду. Однако, системы на основе MOM как правило не поддерживают автоматическое преобразование форматов (marshalling/unmarshalling), что требует от разработчика решения задач по преобразованию форматов данных.

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

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

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