Лекция Доступ к бд > rpc icon

Лекция Доступ к бд > rpc




Скачать 145.25 Kb.
НазваниеЛекция Доступ к бд > rpc
Дата27.07.2013
Размер145.25 Kb.
ТипЛекция
источник

Distributed Software, TSU, FAMC, 2007

Лекция 1.

1. Доступ к БД

2. RPC


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

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

Как я уже говорил ключевым компонентом RPC является язык описания интерфейсов предназначенный для определения интерфейсов, которые задают контрактные отношения между клиентом и сервером. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения. Язык IDL обеспечивает независимость механизма RPC от языков программирования – вызывая удаленную процедуру, клиент может использовать свои языковые конструкции, которые IDL-компилятор преобразует в свои описания. И обратно, на сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализован серверный процесс.

На базе собственной реализации RPC компания Sun в конце 80-х создала среду открытых сетевых вычислений ONC (open network computing), которая, в частности, включает сетевую файловую систему NFS. Однако большинство систем этой категории MW базируется на стандарте Open Group DCЕ RPC. DCE (Distributed Computing Environment) свободно распространяется в виде исходных кодов и существует в реализациях ряда поставщиков, которые настраивают этот код на определенную операционную систему. Помимо базового механизма взаимодействия распределенных приложений, в DCE реализованы некоторые важные для распределенной среды службы, такие как служба каталогов, средства защиты и распределенная файловая система.

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

Для полноты картины надо упомянуть о том, что существуют асинхронные реализации механизма RPC (например, NobleNet RPC или в системе Entera компании Borland). Асинхронный RPC не блокирует выполнение клиентского процесса на время выполнения запроса. Этот вариант удаленного вызова обеспечивает более масштабируемые решения, поскольку значительно сокращает объем поддерживаемой информации о соединении и сеансе связи между клиентом и сервером.
^

Message Oriented Middleware


MOM - промежуточное ПО, ориентированное на обработку сообщений (Message Oriented Middleware. Согласно этой модели приложения обмениваются байтовыми строками – сообщениями, обращаясь к АPI-интерфейсу системы МОМ, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от RPC, МОМ реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложениями. МОМ-системы поддерживают как синхронные, так и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения. По способу обмена сообщениями все продукты МОМ разбиваются на три подгруппы: передача сообщений, очереди сообщений, подписка/публикация.

Системы с передачей сообщений (message passing) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Обмен сообщениями может происходить в синхронном и асинхронном режиме.

Большая часть МОМ-систем реализует асинхронный механизм очередей сообщений (message queuing, MQ). В отличие от передачи сообщений, эта модель межпрограммного взаимодействия не требует поддержки непосредственного соединения одного прикладного модуля с другим, но гарантирует доставку сообщения даже в том случае, если программа-адресат в данный момент не доступна. Программа-отправитель передает сообщение MQ-системе и продолжает выполнение. Сообщение помещается в локальное промежуточное хранилище – очередь сообщений, размещенную в оперативной памяти или на диске, откуда оно может быть немедленно или через какое-то время передано программе-получателю (рис. 2)




^ Рисунок 1. Схема MOM.

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

Большинство MQ-систем включает менеджер очереди (Queue Manager), который управляет локальными очередями, гарантирует передачу сообщений нужному адресату и, взаимодействуя с менеджерами на других узлах, следит за сетевым маршрутом передачи сообщения, выбирая альтернативный путь, если по тем или иным причинам основной оказывается недоступен. Очереди сообщений могут быть долговременными (persistent) или нет. В последнем случае, если произойдет сбой в работе менеджера очередей то сообщения в очереди будут потеряны. Если поддерживается долговременная очередь, сообщения будут восстановлены после перезапуска менеджера. Этот вариант безусловно предпочтительней для таких приложений, как, например, передача банковских средств.

Существует еще одна модель обмена сообщениями – модель подписки/публикации (publish&subscribe). Одно приложение публикует информацию в сети, а другое подписывается для получения данных по интересующей его теме. Фактически, это вариант реализации шаблона Observer в распределенной среде. Взаимодействующие таким способом приложения полностью независимы друг от друга и могут ничего не знать о существовании, физическом размещении и состоянии друг друга. Это открывает путь к динамической реконфигурации всей распределенной системы, добавлению и произвольному изменению любых клиентов и серверов без прерывания их работы и полной изоляции прикладных компонентов от любых аспектов реализации других частей системы. В конечном итоге, это означает возможность эффективной интеграции различных бизнес-приложений в единое корпоративное решение.
^

Transaction Processing Monitor

Доступ к БД


Системы прозрачного доступа к БД представляют собой наиболее развитый сектор рынка MW. Кроме небольших производителей свои решения здесь предлагают такие крупные поставщики СУБД, как IBM, Oracle, Sybase, Siemens и Software AG. В простых двухзвенных моделях клиент-сервер, где несколько баз данных обслуживают ограниченное число пользователей настольных ПК, в роли встроенного MW доступа к данным могут выступать обычные ODBC-драйверы. Необходимость в более сложных решениях возникает в больших, разнородных многозвенных системах, где множество приложений в параллельном режиме осуществляет доступ к разнообразным источникам данных, включая СУБД и хранилища данных от различных поставщиков. В таких системах между клиентами и серверами баз данных размещается промежуточное звено – SQL-шлюз, который представляет собой набор общих API, позволяющих разработчику строить унифицированные запросы к разнородным данным (в формате SQL или с помощью ODBC-интерфейса). SQL-шлюз выполняет синтаксический разбор такого запроса, анализирует и оптимизирует его и в конце концов выполняет преобразование в SQL-диалект нужной СУБД. MW этого типа реализует синхронный механизм связи, когда выполнение приложения, сделавшего запрос, блокируется до момента получения данных. Надо заметить, что синхронные принципы взаимодействия в распределенной среде, как правило, порождают проблемы масштабируемости системы. На рисунке 9 изображена схема MW, предназначенного для доступа к БД.




Рисунок 2. MW для доступа к БД
^

Собственно TP



Порядка 20 лет мониторы обработки транзакций (transaction processing – TP) активно использовались на мэйнфреймах для реализации банковских, страховых и других высококритичных систем. К середине 90-х вместе с миграцией таких приложений в среду клиент-сервер на базе UNIX и Windows NT, старые ТР-мониторы, стали переноситься на новые платформы

Первоначально основной задачей ТР-монитора в среде клиент-сервер было сокращение числа соединений клиентских систем с базами данных. При непосредственном обращении клиента к серверу базы данных для каждого клиента устанавливается соединение с СУБД, которое порождает запуск отдельного процесса UNIX. ТР-мониторы брали на себя роль концентратора таких соединений, становясь посредником между клиентом и сервером базы данных.

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

ТР-мониторы представляют собой одну из самых сложных и многофункциональных технологий в мире промежуточного ПО. Основное их назначение – автоматизированная поддержка приложений, оформленных в виде последовательности транзакций. Каждая транзакция – это законченный блок обращений к ресурсу (как правило, базе данных) и некоторых действий над ним, для которого гарантируется выполнение четырех условий, так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability).

  • ^ Atomicity (атомарность) – операции транзакции образуют неразделимый, атомарный блок («unit of work») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;

  • ^ Consistency (согласованность) – по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;

  • Isolation (изолированность) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;

  • ^ Durability (долговременность) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.

В системе без ТР-монитора, обеспечение свойств ACID берут на себя серверы распределенной базы данных (на основе протокола 2РС – two-phase commit). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции.



^ Рисунок 3. Распределенная обработка транзакций

Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому, для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, без монитора транзакций не обойтись. ТР-мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру ХА, которая является стандартом для данной категории MW. ХА определяет интерфейс для взаимодействия ТР-монитора с менеджером ресурсов, например, СУБД Oracle или Sybase. Спецификация ХА является частью общего стандарта распределенной обработки транзакций (distributed transaction processing – DTP), разработанного X/Open (рис.3).

Архитектура DTP поддерживает совместное использование ресурсов (файлов или баз данных) множеством программ, обеспечивая управление доступом, гарантирующее согласованность системы в целом. Одна транзакция может, например, одновременно удалять запись из базы данных Oracle на Unix-сервере и модифицировать запись в DB2 на мэйнфрейме.

Функции современных ТР-мониторов не ограничиваются поддержкой целостности прикладных транзакций. Большинство продуктов этой категории способны распределять, планировать и выделять приоритеты запросам нескольких приложений одновременно, тем самым сокращая процессорную нагрузку и время отклика системы.

ТР-мониторы выполняют мультиплексирование запросов к ресурсам от множества клиентов. В большинстве приложений фактический доступ пользователя к базе данных занимает лишь часть общего времени соединения. ТР-монитор будет обслуживать, например, 100 клиентов при помощи 10 активных соединений с ресурсом. Таким образом, снимается одно из серьезных ограничений производительности и масштабируемости клиент-серверной среды – необходимость поддержки отдельного соединения с базой данных для каждого клиента. Многие ТР-мониторы имеют возможность оптимально распределять нагрузку на серверы, а также выполнять автоматическое восстановление после сбоя и перезапуск системы.

Таким образом, ТР-монитор – это не только механизм коммуникаций, но и мощная платформа для реализации логики приложения, хороший кандидат на промежуточное звено многозвенной архитектуры клиент-сервер.
^

Средства интеграции распределенных объектов


Мы рассмотрим два варианта объектного промежуточного ПО – стандартная архитектура брокеров объектных запросов CORBA, поддерживаемая консорциумом OMG, и разработка COM/DCOM компании Microsoft. Обе распространяют принципы вызова удаленных процедур на объектные распределенные приложения и обеспечивают прозрачность реализации и физического размещения серверного объекта для клиентской части приложения; поддерживают возможность взаимодействия объектов, созданных на различных ОО-языках и скрывают от приложения детали сетевого взаимодействия. В DCOM взаимодействие удаленных объектов базируется на спецификации DCE RPC, а CORBA опирается на брокера объектных запросов (ORB). ORB обеспечивает передачу объектных запросов, поиск необходимых объектных сервисов и возврат результатов клиенту. Как и в стандарте DCE RPC, ключевым компонентом архитектуры CORBA является язык описания интерфейсов IDL, на уровне которого поддерживаются «контрактные» отношения между клиентом и сервером и обеспечивается независимость от конкретного ОО-языка. В отличие от DCE IDL, CORBA IDL поддерживает основные понятия объектно-ориентированной парадигмы (инкапсуляцию, полиморфизм и наследование). В модели DCOM также может использоваться язык IDL собственной разработки Microsoft, который, однако, играет вспомогательную роль и используется в основном для удобства описания объектов. Реальная интеграция объектов в DCOM происходит не на уровне абстрактных интерфейсов, а на уровне бинарных кодов, и это одно из основных различий двух объектных моделей.

И DCOM, и CORBA, в отличие от процедурного RPC, дают возможность динамического связывания удаленных объектов (клиент может обратиться к серверу-объекту во время выполнения, не имея информации об этом объекте на этапе компиляции). В CORBA для этого существует специальный интерфейс динамического вызова DII, а СОМ использует механизм OLE Automation. Информацию о доступных объектах сервера на этапе выполнения клиентская часть программы получает из специального хранилища метаданных об объектах – репозитария интерфейсов Interface Repositary в случае CORBA и библиотеки типов (Type Library) в модели DCOM. Эта возможность очень ценна для больших распределенных приложений, поскольку позволяет менять и расширять функциональность серверов, не внося существенных изменений в код клиентских компонентов программы, которых в корпоративной системе может быть множество. Пример – банковское приложение, основная бизнес-логика которого поддерживается сервером в центральном офисе, а клиентские системы разбросаны по филиалам в разных городах. Однако, многие отмечают, что механизм динамического вызова CORBA сложен в реализации.

Архитектура CORBA – это спецификация, которая помимо механизма взаимодействия с помощью ORB включает в себя ряд общих служб CORBAServices (служба каталогов, защиты, оповещения о событиях, поддержки транзакций и ряд других), а также реализаций объектов для разных прикладных областей. Компании-поставщики используют эту спецификацию для создания собственных продуктов, которые могут взаимодействовать друг с другом по протоколу IIOP.

Спектр поддерживаемых служб для разных систем варьируется. Существуют десятки реализаций CORBA, с полным списком которых можно познакомиться на сервере ОMG www.corba.org/vendors: Iona Orbix, Inprise VisiBroker и BEA ObjectBroker – лишь некоторые из наиболее известных названий коммерческих ORB.

Основная реализация DСОМ принадлежит Microsoft и интегрирована в Windows. Приобретая Windows пользователь получит все возможности объектного взаимодействия DCOM. С помощью своих партнеров Digital и Software AG компания Microsoft предпринимает попытки портировать СОМ и на другие операционные системы – Unix и OpenVMS. Однако, CORBA, изначально нацеленная на кроссплатформную поддержку и реализованная для всех разновидностей Unix, всех версий Windows и многих других важных ОС, имеет очевидное преимущество перед объектной моделью Microsoft.

С другой стороны, Microsoft стремится интегрировать DCOM со средствами разработки приложений, с тем чтобы максимально упростить создание клиент-серверных систем на базе этой технологии. Большинство популярных сред разработки, в том числе PowerBuilder, VisualC++, VisualBasic и Delphi имеют встроенную поддержку DCOM.

В общем, в свое время, технологии интеграции распределенных объектов OMG и Microsoft были достаточно четко разграничивают сферы влияния – CORBA успешно обслуживала большие гетерогенные системы, а СОМ/DCOM использовалась в менее масштабных проектах из мира Windows.

К разговору о CORBA мы еще вернемся…
^

Мониторы компонентных транзакций (СТМ)


Технология СТМ выросла из технологий интеграции распределенных объектов и ТР-мониторов. СТМ - это гибрид двух технологий, представляющий собой мощную платформу для распределенных объектов.

Мониторы ТР существуют уже достаточно долгое время, поэтому технология, лежащая в их основе, стала прочной, как камень. Вот почему они сегодня применяются во многих прикладных системах. Но мониторы ТР не являются объектно-ориентированными. Они работают с процедурным кодом, способным выполнять сложные задачи, но не имеющим представления об объектах. Доступ к мониторам ТР через RPC похож на вызов статических методов, здесь не существует понятия уникального объекта. Кроме этого, по той причине, что мониторы ТР основаны на процедурных приложениях, а не на объектах, прикладная логика в мониторах ТР не является гибкой, расширяемой или многократно используемой, как у прикладных объектов в системах с распределенными объектами. Технологии интеграции распределенных объектов лишены этого недостатка, но они не являются «операционными системами» для распределенных объектов. Они представляют собой просто коммуникационный каркас, используемый для доступа и взаимодействия с уникальными удаленными объектами. Недостаток инфраструктуры системного уровня создает многочисленные проблемы для разработчика приложения. Создание такой инфраструктуры, требующей обработки параллелизма, транзакций, безопасности, постоянства и кроме этого нуждающейся в поддержке большого количества пользователей, является задачей, достойной Геркулеса, которую способны решить очень немногие корпоративные коллективы разработчиков.
^
СТМ: гибрид ОRB и ТР-мониторов

После тридцатилетнего опыта работы с мониторами ТР компании, такие как IBM и ВЕА, начали разработку гибрида систем распределенных объектов и ТР-мониторов, названного мониторами компонентных транзакций (СТМ). Этот тип серверов приложений соединяет в себе гибкость и доступность систем распределенных объектов, основанных на технологиях распределенных объектов с мощностью «операционных систем» мониторов ТР. СТМ предоставляют комплексную среду для серверных компонентов, обеспечивая автоматическое управление параллелизмом, транзакциями, распределением объектов, выравниванием загрузки, безопасностью и ресурсами. Хотя разработчики приложений по-прежнему должны быть знакомы с этими возможностями, в случае применения СТМ им нет необходимости явно реализовывать их.

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

СТМ требуют, чтобы прикладные объекты придерживались модели серверных компонентов, реализованной производителем. Удачная модель компонентов представляет собой решающий фактор успеха разрабатываемого проекта, т. к. она определяет, насколько легко разработчик приложения может написать прикладной объект под данный СТМ. Модель компонентов является соглашением, определяющим обязанности СТМ и прикладных объектов. Имея дело с удачной компонентной моделью, разработчик знает, что можно ожидать от СТМ, а СТМ «понимает», как следует управлять прикладными объектами. Модели серверных компонентов хорошо подходят для описания обязанностей разработчика приложения и производителя СТМ.

Модели серверных компонентов опираются на определенную спецификацию. Если компонент придерживается этой спецификации, он может быть использован СТМ. Отношения между серверным компонентом и СТМ похожи на отношения между CD-диском и CD-проигрывателем. Если компонент (CD-диск) придерживается спецификации проигрывателя, он может быть воспроизведен на нем.

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

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

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





Добавить документ в свой блог или на сайт


Похожие:

Лекция Доступ к бд > rpc iconЛекция 12 Структура лекции
Наука в современной России А. Сунгуров Курс «Логика и методология науки», Лекция 12

Лекция Доступ к бд > rpc iconДокументы
1. /Доступ к COM серверам Microsoft Office из Delphi 5/Доступ к COM серверам Microsoft Office...

Лекция Доступ к бд > rpc icon1. Лекция. Понятие публичной политики Тема Лекция. Понятие публичной политики >19. 04
Тема Лекция. Институты-медиаторы как важный компонент развития публичной политики и становления консолидированной демократии

Лекция Доступ к бд > rpc iconЛекция №1 Лекция Часть II
...

Лекция Доступ к бд > rpc iconДокументы
1. /Контрольная работа/Контрольная.doc
2. /Контрольная...

Лекция Доступ к бд > rpc iconЛекция 5 Функция «задания правил игры» или принятия законов
Функции принятия «правил игры и их реализации структуры представительной и исполнительной власти А. Сунгуров Введение в специальность...

Лекция Доступ к бд > rpc iconСообщение о порядке доступа к информации, содержащейся в ежеквартальном отчете
...

Разместите кнопку на своём сайте:
Документы


База данных защищена авторским правом ©lapdoc.ru 2000-2014
При копировании материала укажите ссылку.
обратиться к администрации
Документы