Lektsia 5

Лекция 5. Промежуточное программное обеспечение
[ Cкачайте файл, чтобы посмотреть картинку ][ Cкачайте файл, чтобы посмотреть ссылку ][ Cкачайте файл, чтобы посмотреть ссылку ][ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
[ Cкачайте файл, чтобы посмотреть ссылку ]
Эволюция архитектуры «клиент-сервер»
Классическая [ Cкачайте файл, чтобы посмотреть ссылку ] вполне подходит для небольших корпоративных подразделений с ограниченным числом пользователей и невысокой нагрузкой на сервер. Однако, по мере внедрения клиент-серверных технологий в сферу высококритичных корпоративных приложений, обслуживающих сотни пользователей и обрабатывающих существенные массивы данных, стали очевидны недостатки двухзвенных решений:
ограниченные возможности масштабирования;
необходимость изменения клиентских приложений при изменении работы серверной логики.
Решить эти проблемы позволяет переход на трех- и многозвенные модели, в которых прикладная логика вынесена в отдельный уровень (на сервер приложений). Это позволяет эффективно распределять нагрузку и обеспечить прозрачное наращивание как функциональности сервера (серверов) приложений, так и числа обслуживаемых пользователей.
Но, для перехода на трехзвенную архитектуру зачастую приходится решить другую проблему: как обеспечить взаимодействие имеющихся компонентов, от которых нельзя отказаться по тем или иным причинам, с компонентами новой системы. Т.е. возникает вопрос интеграции приложений. Ответом на этот вопрос является использование специализированного, т.н. промежуточного, программного обеспечения middleware.
Определение и назначение промежуточного ПО
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 1. Промежуточное программное обеспечение
Промежуточное программное обеспечение (middleware) это класс программного обеспечения, предназначенного для объединения компонентов распределенного клиент-серверного приложения или целых сетевых приложений в единую информационную систему. Промежуточное ПО представляет набор сервисов, обращение к которым позволяет различным приложениям, в общем случае выполняющимся на разных платформах, взаимодействовать между собой ([ Cкачайте файл, чтобы посмотреть ссылку ]). Общие прикладные интерфейсы (API) промежуточного ПО позволяют реализовать взаимодействие между приложениями, не углубляясь в инфраструктуру и детали реализации гетерогенной сети, а последующие изменения в структуре и составе такой сети не потребуют изменений в приложениях (при условии, что эти изменения не затрагивают API middleware).
Термин middleware впервые был использован в 1968 г., но как технология интеграции корпоративных приложений, этот тип программного обеспечения стал использоваться с 80-х годов XX в. для решения проблем совместимости и взаимодействия новых приложений с устаревшими наследованными системами.
Место промежуточного ПО в условной «середине» между сетевыми приложениями или их компонентами. Этим оно напоминает среднее звено в трехзвенных клиент-серверных архитектурах, за исключением того, что функциональные части middleware распределены между приложениями и/или их компонентами в корпоративной сетевой среде.
Функции middleware
Сервисы middleware представляют приложениям разнобразные функции API, которые, в сравнении с функциями операционных систем и сетевых служб, обеспечивают:
прозрачный доступ к другим сетевым сервисам и приложениям;
независимость от других сетевых сервисов;
высокую надежность и постоянную готовность.
Следует отметить, что зачастую различия в функциональности операционной системы и промежуточного ПО являются условными. В частности, некоторые возможности, ранее представляемые исключительно средствами middleware, теперь реализуются на уровне ядра операционных систем. Типичным примером является стек TCP/IP, поддержка которого включена практически во все ОС.
Виды промежуточного ПО
Востребованность промежуточного ПО при разработке и внедрении сложных систем привела к появлению различных типов middleware, которые отличаются масштабируемостью, надежностью и самой идеей организации взаимодействия. При этом весь существующий на сегодняшний день спектр промежуточного ПО можно условно разделить на две основных категории (по специализации):
Программное обеспечение для межпрограммного взаимодействия (см. также [ Cкачайте файл, чтобы посмотреть ссылку ]).
Программное обеспечение доступа к базам данных.
Промежуточное ПО межпрограммного взаимодействия
Протоколы и продукты этой категории облегчают межпроцессные взаимодействия (IPC - InterProcess Communications) и распределение объектов в инфраструктуре корпоративной информационной системы. Они выполняют роль клея, позволяющего соединить многозвенные приложения. Основными технологиями являются следующие: RPC, MOM, TPM и ORB. В готовых решениях, как правило, используется один или несколько таких протоколов.
Вызов удаленных процедур
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 2. Вызов удаленных процедур
Концепция вызова удаленных процедур (remote procedure call RPC) была разработана и реализована в компанией XEROX еще начале 80-х годов XX века. Общий смысл RPC можно представить так: программа может выполнять не только собственные (скомпилированные) процедуры и функции, но и обращаться к процедурам удаленного сервера ([ Cкачайте файл, чтобы посмотреть ссылку ]).
Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – «заглушкам», соответственно клиентской и серверной (client stub и server stub). Эти stub'ы не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) приложений. Все RPC-обращения клиента (имена функций и списки параметров) упаковываются клиентской заглушкой в сетевые сообщения (этот процесс называется marshaling) и ей же передаются серверной заглушке. Та, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера, а полученные результаты упаковывает в обратном порядке. Клиентская заглушка принимает ответ, распаковывает его и возвращает в приложение. Таким образом, процедуры-заглушки изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций.
В этом случае вызов удаленной процедуры осуществляется миллион раз и на каждой итерации циклов будут выполняться операции по установлению соединения между клиентом и сервером, передаче данных и разрыву соединения. Это приведет к существенной нагрузке на сеть и снижению производительности системы. Правильнее в этом случае обеспечить возможность управления соединением вне тела циклов, что противоречит самой идее RPC.
Для определения правил, задающих отношения между клиентом и сервером RPC, используется язык описания интерфейсов IDL. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения. Правила IDL обеспечивают независимость механизма RPC от языков программирования: обращаясь к удаленной процедуре, клиент использует свои языковые конструкции, а IDL-компилятор преобразует их в унифицированные описания, понятные серверу. На сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализован серверный процесс.
У RPC как средства организации сетевого взаимодействия есть ряд минусов, кроющихся в самой парадигме структурного программирования:
Синхронные запросы RPC приостанавливает выполнение приложения до тех пор, пока сервер не вернет требуемые данные.
Статические отношения между компонентами привязка клиентского процесса к серверным заглушкам происходит на этапе компиляции и не может быть изменена во время выполнения.
Для устранения этих недостатков были разработаны более совершенные механизмы реализации RPC:
асинхронные RPC, позволяющие избежать приостановки выполнения клиентского приложения посредством функций обратного вызова (call-back functions);
код заглушек вынесен в динамически подключаемые библиотеки.
Протокол взаимодействия RPC также может повлиять на работу системы. Рассмотрим гипотетический фрагмент кода:
for (i = 0, i < 1000, i++)
for (j = 0, j < 1000, j++)
RPC_call();
В этом случае вызов удаленной процедуры будет выполняться миллион раз. На каждой итерации будут выполняться действия не только по передаче данных и результатов, но и по управлению соединением. Это приведет не только к повышению нагрузки на сеть, но и снижению производительности системы в целом. В данном случае правильным решением является вынос функций установления и разрыва соединения за тело циклов, что противоречит самой идее RPC.
См. также: [ Cкачайте файл, чтобы посмотреть ссылку ] (Sun Microsystems), [ Cкачайте файл, чтобы посмотреть ссылку ] (The OpenGroup Distributed Computing Environment (DCE))
Сервисы обработки сообщений
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 3. Промежуточное обеспечение, ориентированное на обработку сообщений (MOM)
Следующий вид промежуточного ПО это сервисы обработки сообщений (MOM message-oriented middleware). К этой категории относятся системы, как правило асинхронные, в которых взаимодействие между клиентом и сервером основано на обмене сообщениями. Сообщения это текстовые блоки, состоящие из управляющих команд и передаваемых данных. Для передачи сообщений используются байт-ориентированные протоколы (HTTP, POP/SMTP и т.п.).
Обмен сообщениями реализуется через API системы MOM. Запросы сервисов ставятся в очередь сообщений и обрабатываются в соответствии с приоритетами и доступностью ресурсов. Приоритеты сообщений позволяют обеспечить первоочередную доставку важных сообщений, а отложенная доставка осуществляется либо по расписанию, либо при появлении адресата в сети. Ответы сервера содержат информацию об успешном или неуспешном выполнении операции.
Сервисы MOM хорошо зарекомендовали себя в сильно распределенных приложениях, используемых в гетерогенной сети с медленными и ненадежными соединениями. Это, во-многом, достигается благодаря поддержке уровней «качества обслуживания»:
надежная доставка сообщений (reliable message delivery) система MOM гарантирует, что в процессе обмена ни одно сообщение не будет утеряно;
гарантированная доставка сообщений (guaranteed message delivery) сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);
застрахованная доставка сообщений (assured message delivery) каждое сообщение доставляется только один раз.
Очереди сообщений представляют собой мощный, гибкий и в то же время простой механизм межпрограммного взаимодействия.
Помимо приведенной, можно сказать классической, схемы с очередями, разработаны и используются сервисы MOM с непосредственной передачей сообщений и на основе подписки.
Системы с непосредственной передачей сообщений (message passing) используют логическое сетевое соединение для обмена сообщениями между взаимодействующими приложениями. Эта схема удобна в тех случаях, когда клиенты и серверы сообщений используются в сильно связанной сетевой инфраструктуре и синхронизированы по времени.
Сервисы MOM, обслуживающие клиентов по подписке/публикации (publish&subscribe) работают по принципу, напоминающему почтовую рассылку: одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для получения необходимых данных. Взаимодействующие таким способом приложения полностью независимы друг от друга, что представляет возможности динамической реконфигурации всей распределенной системы.
Мониторы обработки транзакций (TP-Monitors)
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 4. Монитор транзакций
Мониторы транзакций (Transaction Processing monitors, TP-monitors) это промежуточное программное обеспечение, обеспечивающее контроль передачи данных от клиента при работе с распределенными базами данных. Монитор транзакций обеспечивает целостность данных, следя за тем, чтобы не было потерянных или незавершенных транзакций. Транзакция – это законченный блок обращений к базе данных, для которого гарантируется выполнение четырех условий ACID:
Атомарность (Atomicity) – операции транзакции образуют неделимый, атомарный блок, который либо выполняется от начала до конца, либо не выполняется вообще. При невозможности выполнения транзакции происходит откат к исходному состоянию;
Согласованность (Consistency) – по завершении транзакции все задействованные ресурсы находятся в предопределенном и согласованном состоянии;
Изолированность (Isolation) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы исключить их влияние друг на друга;
Долговременность (Durability) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.
Монитор транзакций обеспечивает контроль над выполнением этих условий, выполняя функции концентрации и преренаправления запросов к БД в распределенной среде с множеством баз данных от различных поставщиков. Подробное описание открытой спецификации [ Cкачайте файл, чтобы посмотреть ссылку ] доступно на сайте OpenGroup.
Распределенные объектные системы
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 5. Распределенные объектные системы (stub и skeleton - клиентская и серверная заглушки)
Распределенные объектные системы (Distributed object systems) это промежуточное программное обеспечение, реализованное в виде взаимодействующих друг с другом программных объектов. Каждый такой объект уникальным образом идентифицируется в сети и обеспечивает доступ к представляемым им сервисам через публичные свойства и методы. Реализация объекта и платформа, на которой он выполняется, полностью прозрачны для клиента.
С точки зрения разработки, использование распределенных объектов оправданно при создании масштабных объектно-ориентированных систем. Фактически же, объектная «обертка» таких решений скрывает за собой ранее рассмотренные RPC, MOM и средства управления транзакциями. По-этому, в первом приближении общий принцип взаимодействия распределенных объектов очень похож на RPC ([ Cкачайте файл, чтобы посмотреть ссылку ]). Это сходство заметно и в средствах описания интерфейсов объекты используют все тот же IDL. Однако, в сравнении с RPC, распределенные объекты могут компоноваться динамически, т.е. не на этапе компиляции, а во время выполнения приложений.
Архитектура распределенных объектных систем стандартизована и наиболее распространены спецификации CORBA, COM/DCOM и EJB.
CORBA (Common Object Request Broker Architecture, типовая архитектура брокера объектных запросов) открытый стандарт, разработанный группой [ Cкачайте файл, чтобы посмотреть ссылку ], который определяет интерфейсы между сетевыми объектами, позволяющие им работать совместно. Брокеры объектных запросов (object request brokers, ORB), созданные в соответствии с CORBA, представляют интерфейсы для разработки объектно-ориентированных систем «клиент-сервер».
Microsoft COM (Component Object Model, компонентная объектная модель) это семейство технологий, предназначенных для организации взаимодействия Windows-приложений (см. [ Cкачайте файл, чтобы посмотреть ссылку ]). В это семейство входят COM+, DCOM (Distributed COM) и ActiveX Controls. Microsoft позиционирует COM как платформу для разработки повторно используемых (re-usable) компонентов приложений. В случае DCOM компонентов распределенных клиент-серверных систем.
EJB (Enterprise JavaBeans) технология, разработанная Sun Microsystems для корпоративных решений на платформе Java ([ Cкачайте файл, чтобы посмотреть ссылку ]). Спецификация EJB описывает архитектуру серверных компонентов и порядок их использования в клиент-серверных приложениях. Эта технология упрощает разработку распределенных систем на основе Java и обеспечивает наибольшую переносимость Java-приложений.
Промежуточное ПО доступа к базам данных
Рассмотрим два основных типа промежуточного обеспечения, ориентированного на работу с распределенными данными это собственное промежуточное обеспечение СУБД и основное промежуточное обеспечение баз данных.
Собственное промежуточное ПО СУБД это встроенные механизмы доступа для конкретного сервера баз данных.
Основное промежуточное ПО баз данных к этому типу относится, например, интерфейс Open Database Connectivity (ODBC), который позволяет программам «общаться» на разных диалектах SQL через общие интерфейсы.
Собственное ПО промежуточного слоя
К этому виду относится, в первую очередь, поддержка стандартов языка SQL. Несмотря на то, что SQL является международным стандартом, разработчики СУБД самостоятельно определяют, какие из возможностей SQL они будут поддерживать в своих системах. В результате, конкретная СУБД может, с одной стороны, не поддерживать или поддерживать частично некоторые команды SQL, а с другой представлять разработчикам приложений нестандартные языковые расширения.
Другим видом собственного middleware являются встроенные средства СУБД, позволяющие выполнять импорт данных из внешних источников (например, из других СУБД или текстовых файлов) и экспортировать данные в сторонние форматы (например, CSV или XML).
Основное промежуточное ПО доступа к БД
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 6. Доступ к БД через ODBC
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 7. Интерфейс ODBC (Open DataBase Connectivity)
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 8. Принцип доступа к БД в EDA
[ Cкачайте файл, чтобы посмотреть ссылку ]
Рис. 9. Брокер распределенных запросов (DQB)
К этой категории относятся внешние (по отношению к СУБД) средства промежуточного слоя, специально разработанные для обращения к базам данных. Сюда относятся как технологические решения (например, ODBC и JDBC), так и концептуальные, представляющие обобщенную архитектуру информационной системы с распределенными БД (например, EDA или DQB).
ODBC ([ Cкачайте файл, чтобы посмотреть ссылку ], открытое соединение с БД) это интерфейс доступа к базам данных, разработанный Microsoft. ODBC представляет возможность обращения к реляционным и нереляционным СУБД в гетерогенной среде через унифицированные вызовы API ([ Cкачайте файл, чтобы посмотреть ссылку ]). Обращения к функциям ODBC транслируются в естественные диалекты многих СУБД с помощью специальных ODBC-драйверов либо напрямую, либо через указание имени источника данных ([ Cкачайте файл, чтобы посмотреть ссылку ]).
JDBC ([ Cкачайте файл, чтобы посмотреть ссылку ]) это прикладной программный интерфейс для обращения к базам данных из Java-приложений. Средства JDBC являются платформонезависимыми и выполняются в любой среде под управлением виртуальной машины Java. По сравнению с ODBC этот тип промежуточного ПО баз данных предлагает больше возможностей по интеграции приложений и расширяет сферу использования БД (например, в сторону мобильных приложений). Больше того, спецификация JDBC предусматривает возможность доступа Java-приложений к БД через ODBC с помощью специального средства, т.н. «моста» (ODBC/JDBC-bridge).
EDA (Event-Driven Architecture, событийно-управляемая архитектура) это концепция управления корпоративной информационной системой на основе событий, возникающих в бизнес-процессе. Доступ к БД в EDA базируется на использовании централизованного способа обращения к распределенным базам данных. Все запросы клиентов поступают на вход SQL-шлюза, который транслирует SQL-запросы в унифицированный формат и перенаправляет их к серверам БД. Взаимодействие с ними возможно как через набор общих API, так и через ODBC-интерфейс ([ Cкачайте файл, чтобы посмотреть ссылку ]). Использование SQL-шлюза обеспечивает доступ к данным в разнородных многозвенных системах, где множество приложений параллельно обращаются к источникам данных различного формата.
DQB (Distributed Query Broker, брокер распределенных запросов) децентрализованное (в отличие от EDA) решение для доступа к БД на основе ORB. Заглушки-брокеры, размещенные на серверах БД, принимают унифицированные SQL-запросы и транслируют их в диалекты конкретных СУБД ([ Cкачайте файл, чтобы посмотреть ссылку ]).
Middleware: Что выбрать?
Стек протоколов TCP/IP давно уже поддерживается на уровне операционных систем, средства RPC также доступны в сетевых ОС едва ли не "по умолчанию". Этот механизм практически не требует от разработчиков и интеграторов каких-либо новых знаний и навыков. Не требуется изучать специфические middleware API: вызов удаленной процедуры ничем не отличается от обращения к локальной подпрограмме, а все процессы преобразования данных и передачи их по сети выполняются клиентской и серверной заглушками. Использование RPC может быть наиболее подходящим решением для систем, где возможные проблемы, связанные с синхронностью протокола RPC, не являются критичными.
Промежуточное ПО обмена сообщениями предлагает бОльшую, по сравнению с RPC, гибкость, так как ни одно из взаимодействующих приложений не блокируется в процессе обмена сообщениями. Такое решение лучше подойдет для автоматизированных систем, компоненты которых слабо связаны, работают в независимом временном режиме и используют разнородную сетевую среду. Однако, системы на основе MOM как правило не поддерживают автоматическое преобразование форматов (marshalling/unmarshalling), что требует от разработчика решения задач по преобразованию форматов данных.
Взаимодействие компонентов корпоративных приложений в объектно-ориентированной среде удобнее всего реализовывать с помощью объектных-же средств промежуточного ПО. В этом случае, разработчик использует объектную модель, четко описывающую бизнес-процессы. Высокий уровень абстракции объектов (будь то ORB или EJB) полностью скрывает от пользователя детали реализации взаимодействия между ними. Использование объектов позволяет строить корпоративные приложения словно [ Cкачайте файл, чтобы посмотреть ссылку ], из унифицированных «кирпичиков»объектов. Это справедливо, если вся система является объектно-ориентированной. Затруднения с использованием распределенных объектов появляются, когда компонентами автоматированной системы являются унаследованные приложения.
Мониторы транзакций ориентированы на сложные и высококритичные корпоративные системы. Они обеспечивают необходимый уровень сервиса для таких систем, включая управление процессами, балансировку нагрузки на серверы, средства резервирования восстановления данных. Для задач автоматизации небольшого предприятия возможности, представляемые TP-мониторами могут быть избыточны. К тому же, продукты этой категории имеют высокую стоимость, что может быть экономически не выгодно.
Рассмотренные категории промежуточного ПО все реже и реже используются в «чистом» виде. Напротив, как и в большинстве сетевых технологий, развитие middleware идет в сторону объединения возможностей разных его категорий и для разного рода задач всегда можно подобрать наиболее подходящее решение.
Контрольные вопросы
Опишите назначение промежуточного ПО.
Перечислите основные способы организации межпрограммного взаимодействия (типы промежуточного ПО).
Опишите принцип работы промежуточного ПО типа «сервис обмена сообщениями».
Опишите принцип работы сервиса удаленного вызова процедур (RPC).
Опишите принцип работы промежуточного ПО типа «монитор транзакций».
Опишите принцип межпрограммного взаимодействия на основе объектной модели ORB.

type="text/javascript" charset="utf-8" src="//yandex.st/share/share.js"Монитор транзакций Заголовок 1 Заголовок 2 Заголовок 3 Заголовок 415

Приложенные файлы

  • doc 18814041
    Размер файла: 194 kB Загрузок: 0

Добавить комментарий