Основное промежуточное ПО доступа к БД

• 
  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).
  

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

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

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

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

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