Программное обеспечение промежуточного слоя (middleware)

Для повышения степени прозрачности взаимодействия между различными частями распределённой системы вводят понятие программного обеспечения промежуточного слоя (middleware). В общем, ПО промежуточного слоя можно определить как набор компонент предоставляющих типичный набор сервисов для компонент системы реализующих бизнес-логику. Как правило, типичный набор служб промежуточного слоя состоит из [7]:

• Службы связи (communication facilities) – обеспечивают взаимодействие между различными компонентами бизнес-логики
• Службы именования и обнаружения (naming, directory) – обеспечивают механизм задания имён или идентификаторов компонент в пределах распределённой системы, регистрировать компоненты в системе, а так же осуществлять их поиск.
• Сохранение состояния (persistence) – обеспечивают возможность постоянного и долговременного сохранения данных компонента (например в файле или БД).
• Службы распределённых транзакций (distributed transaction service).
• Безопасность (security) – предоставляет распределённые и прозрачные механизмы аутентификации и авторизации.

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

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

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

• Синхронный или асинхронный;
• С подтверждением или без подтверждения;
• С поддержкой или без поддержки транзакционности.
• С гарантированной или без гарантированной доставки.

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

Взаимодействие построенное на основе обмена сообщениями обладает по мимо неоспоримых достоинств и рядом существенных недостатков. К ним относятся:

• Большие задержки взаимодействия обусловленные затратой ресурсов на формирование, пересылку, получение и распаковку сообщения. Кроме того, если используется гарантированная или транзакционная доставка сообщений дополнительные ресурсы расходуются ещё интенсивнее на обеспечение соответствующей инфраструктуры.
• Часто сообщения кодируются в формате основанном на XML, что позволяет существенно улучшить открытость взаимодействия, однако вносит ещё большие накладные расходы на мершалинг/демаршалинг (формирование и парсинг документа XML).

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

В технологии Java службой, предоставляющей связь на основе передачи сообщений является JMS (Java Message Service)[8]. Это специфицированный набор API определяющий сервисы по предоставлению услуг обмена сообщениями в двух моделях:

• Подписчик-получатель (Publish-Subscribe)
• Точка-точка (peer-to-peer)

Модель Publish-Subscribe предполагает наличие нескольких потребителей, привязанных к одной очереди сообщений и одного или более производителей, публикующих сообщения в эту очередь. При этом КАЖДЫЙ потребитель получит копию сообщения.

Модель peer-to-peer предполагает наличие очереди, из которой сообщение доставляется ЛЮБОМУ готовому подписчику (их может быть больше одного), при этом сообщение получит только ОДИН из подписчиков.

Реализация служб именования и обнаружения как правило представляется в виде распределённых или централизованных каталогов. Наиболее известным примером такой службы является DNS (Domain Naming System) [9,10]. Основной задачей такой службы является выработка и поддержание справочника глобальных имей и их соответствия ресурсам. Дополнительно может поддерживаться поиск по различным атрибутам, специфичным для доменной области. (Например, поиск людей не только по первичному и уникальному ключу, которым в пределах государства является номер и серия паспорта, но в дополнение к этому поиск по имени и фамилии, которые вообще говоря не уникальны).

Наиболее широко применяемой службой каталога являются службы, построенные на основе протокола LDAP (Lightweight Directory Access Protocol) [11].

Кроме этого, в среде Windows широко используется служба Active Directory (которая так же может предоставлять свои услуги по протоколу LDAP). Другим примером может являться Novell NDS.

В среде Java используется служба JNDI (Java Naming and Directory Interface). Это набор интерфейсов, аналогичных LDAP позволяющих регистрировать и искать сервисы и компоненты в едином глобальном (в масштабе сервера JNDI) справочнике. Служба JNDI широко используется в повседневной практике программирования на J2EE при работе с такими ресурсами как Database Connection, DataSource, EJB. Например настроенный DataSource может быть зарегистрирован в службе JNDI сервера приложений, после чего он становиться доступным всем приложениям (в соответствии с заданной политикой безопасности) развёрнутым в контексте этого сервера через стандартный интерфейс JNDI. Этим достигается низкая привязанность к конкретной реализации DataSource.

Дата добавления: 2014-01-05