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

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

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

О возможностях и свойствах ПО промежуточного слоя можно прочитать в статье Ф. Бернстайна "Middleware: модель сервисов распределенной системы" (Jet Info, 1997, 11).

Перечислим основные достоинства ПО ПС, существенные для обеспечения высокой доступности.

ПО ПС уменьшает сложность создания распределенных систем. Подобное ПО берет на себя часть функций, которые в локальном случае выполняют операционные системы;
ПО ПС берет на себя маршрутизацию запросов , позволяя тем самым обеспечить "живучесть" прозрачным для пользователей образом;
ПО ПС осуществляет балансировку загрузки вычислительных мощностей, что также способствует повышению доступности данных;
ПО ПС в состоянии осуществлять тиражирование любой информации, а не только содержимого баз данных. Следовательно, любое приложение можно сделать устойчивым к отказам серверов;
ПО ПС в состоянии отслеживать состояние приложений и при необходимости тиражировать и перезапускать программы, что гарантирует "живучесть" программных систем;
ПО ПС дает возможность прозрачным для пользователей образом выполнять переконфигурирование (и, в частности, наращивание ) серверных компонентов, что позволяет масштабировать систему, сохраняя инвестиции в прикладные системы. Стабильность прикладных систем – важный фактор повышения доступности данных.

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

Меры по обеспечению обслуживаемости направлены на снижение сроков диагностирования и устранения отказов и их последствий.

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

Динамическое переконфигурирование преследует две основные цели:

изоляция отказавших компонентов ;
сохранение работоспособности сервисов .

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

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

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

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

Сущность изобретения: промежуточный эмульсионный слой, образующийся в процессе добычи и подготовки нефти, перекачивают по замкнутому циклу под слой воды и отстаивают, в процессе перекачки промежуточный эмульсионный обрабатывают составом, содержащим неионогенный деэмульгатор на основе блоксополимеров окисей этилена и пропилена, например, Separol WF-34, дипроксамин 157-65М, анионоактивный реагент на основе алкилбензолсульфоната натрия, например сульфонол, и растворитель на основе ароматических углеводородов при массовом соотношении компонентов в составе соответственно 1:(1,75-60):(20-25). 1 табл., 1 ил.

Изобретение относится к нефтегазодобывающей промышленности и применяется для разрушения ловушечных водонефтяных эмульсий. Известен способ обезвоживания нефти, заключающийся в том, что промежуточный слой перед возвращением в процесс обрабатывают струями воды, имеющими напор 2-4 атм, в течение 20-60 мин . Недостатком способа является то, что для его осуществления необходима дополнительная установка, включающая резервуар-накопитель промежуточного слоя, в котором имеется специальное устройство-распределитель с соплами для создания высокоскоростных струй. Известен способ деэмульсации нефтяной эмульсии, заключающийся в обработке эмульсии поверхностно-активным веществом, добавлением воды до обращения фаз эмульсии и дросселировании потока эмульсии при перепаде давления 2-20 атм . Недостатками известного способа являются необходимость добавления большого количества воды в эмульсию и использование специальных дросселирующих устройств, что ведет к повышению энерго- и эксплуатационных затрат на осуществление процесса. Так, например, чтобы повысить обводненность поступающей эмульсии с 60 до 80%, при которой наступит обращение фаз, необходимо добавить такой же объем воды, каков объем эмульсии, а затем пропустить эмульсию через дросселирующее устройство. На практике объем ловушечной эмульсии исчисляется десятками тысяч м 3 , добавление такого же количества воды с последующей подготовкой и транспортированием ее практически затруднено и экономически нецелесообразно, т.к. при этом повышаются энерго- и эксплуатационные затраты на проектирование и строительство дополнительных мощностей (насосы, отстойники, резервуары, расход электроэнергии, обслуживание и т.д.). Наиболее близким по технической сущности и достигаемому результату к предлагаемому способу является способ разрушения промежуточного эмульсионного слоя, образующегося при отстое эмульсии, в соответствии с которым промежуточный слой отбирают из отстойника, обрабатывают деэмульгатором и перекачивают насосом в отстойник под слой воды, замыкая цикл. В отстойнике осуществляется отстой эмульсии , принимаемый за прототип. Недостатком известного способа является низкая эффективность при разрушении промежуточного слоя с повышенным содержанием асфальтено-смолопарафиновых компонентов и механических примесей. Целью изобретения является повышение эффективности разрушения промежуточного эмульсионного слоя с повышенным содержанием асфальтено-смолопарафиновых компонентов и механических примесей. Поставленная цель достигается тем, что в качестве деэмульгатора используют деэмульгирующий состав, содержащий неионогенный деэмульгатор на основе блоксополимеров окисей этилена и пропилена, анионоактиный реагент на основе алкилбензолсульфоната натрия, и растворитель, содержащий ароматические углеводороды, в соотношении 1:(1,75-60):(20-25) соответственно. Сущность изобретения заключается в следующем. Промежуточный эмульсионный слой по физико-химическому составу представляет собой эмульсии как "вода в нефти", так и "нефть в воде". Обводненность эмульсий составляет преимущественно 60-80% , агрегативная устойчивость может достигать 100%, плотность - 0,85-1,2 г/см 3 , вязкость - 12-27 мПа с. В эмульсиях содержится до 43 г/л механических примесей, состоящих в основном из песка и глинистых частиц, в отдельных случаях присутствуют продукты коррозии. Содержание асфальтенов составляет 55-174 г/л, смол - 3-100 г/л, масел и парафинов - 2,6-400 г/л (см. табл). Данные эмульсии не разрушаются обычным термохимическим способом деэмульсации даже при увеличении расхода деэмульгатора до 200-300 г/т. В предлагаемом способе разрушение эмульсии осуществляется путем циркуляции промежуточного слоя насосом перекачки некондиционной нефти через слой дренажной воды в нижнюю часть резервуара по замкнутому циклу по схеме "РВС (резервуар вертикальный стальной) - насос - РВС" с одновременной подачей деэмульгирующего состава на прием центробежного насоса (см. технологическую схему). Способ разрушения может осуществляться как путем однократной, так и многократной циркуляции в зависимости от физико-химических свойств эмульсии (в 1-ю очередь от агрегативной устойчивости), а также от требования к качеству нефти по ГОСТ 9965-76. Количество циклов определяется опытным путем. Как известно, асфальтены, смолы, парафины и мехпримеси являются природными стабилизаторами эмульсий, образующие прочные поверхностные слои на каплях эмульгированной воды или нефти. Для разрушения эмульсий, стабилизированных асфальтенами и смолами, эффективными являются неионогенные деэмульгаторы, для эмульсий, стабилизированных частицами механических примесей, - анионогенные ПАВ, для эмульсий, стабилизированных парафинами, - растворители парафинов. Промежуточные эмульсионные слои, представленные в таблице, содержат все четыре природных стабилизатора, причем в повышенных количествах. Разрушение таких промежуточных эмульсионных слоев достигается за счет использования деэмульгирующего состава по изобретению. Ароматические углеводороды, содержащиеся в составе, обладают высокой растворяющей способностью не только по отношению к парафинам, но также к асфальтенам и смолам, кроме того, они удаляют пленочную нефть, препятствующую слиянию водных капель. Эффективность разрушения эмульсии увеличивается при ее перекачке по схеме "РВС - насос - КСУ (концевая сепарационная установка) - РВС". КСУ представляет собой горизонтальный аппарат, расположенный на высоте 12 м. При прохождении эмульсии через КСУ происходит сепарация газа и дополнительное дросселирование потока эмульсии. По завершении циркуляции и обработки деэмульгирующим составом эмульсия направляется на отстой. Подробное описание реализаций способа. Промежуточный эмульсионный слой берется с выходного патрубка РВС-10000 (резервуар вертикальный стальной - емкостью 10000 м 3), расположенного на высоте 6 м, и поступает на прием насоса перекачки некондициoнной нефти марки ЦНС-180-85, на прием центробежного насоса подается также деэмульгирующий состав дозировочными насосами. Далее обработанная эмульсия центробежным насосом подается в КСУ (концевая сепарационная установка), где происходит сепарация газа и после чего эмульсия возвращается в РВС-10000 и прокачивается через слой дренажной воды через маточник, расположенный на высоте 0,5 м. Эмульсия имеет плотность, меньшую чем дренажная вода, и будет подниматься в верхнюю часть резервуара. В силу того, что эмульсия обработана деэмульгирующим составом, она будет рыхлой и агрегативно не устойчивой, промываясь через слой дренажной воды она будет терять свободно выделившуюся воду из эмульсии, а нефть будет подниматься наверх, так как имеет плотность еще меньшую, чем промежуточный эмульсионный слой. На чертеже показан РВС сбоку, где 1 - технологический резервуар; 2 - дозировочные насосы подачи деэмульгирующего состава; 3 - центробежный насос перекачки некондиционной нефти; 4 - концевая сепарационная установка. Из чертежа следует, что промежуточный слой берут с высоты 6 м и центробежными насосами перекачивают по замкнутому циклу по схеме "РВС - насос - КСУ - РВС", причем эмульсия, обработанная деэмульгирующим составом, возвращается через маточник в слой дренажной воды, где происходит промывка и дальнейшее отстаивание. Увеличивая или уменьшая высоту слоя дренажной воды, можно перемещать промежуточный слой по высоте РВС, т.о. при необходимости можно перекачивать отдельно нефть или промежуточный эмульсионный слой, используя коммуникации трубопроводов комплексного сборного пункта нефти. Опытным путем установлено, что однократная циркуляция с обработкой деэмульгирующим составом и механическими разрушениями в центробежном насосе с последующим дросселированием, промывкой через слой дренажной воды и отстаиванием разрушает до 92-95% стойкой эмульсии. Производительность насоса ЦНС-180-85 при этом равна 180 м 3 /ч. Кратность циркуляции при необходимости можно увеличивать до 3-4. П р и м е р 1. Промежуточный эмульсионный слой (характеристика эмульсии и результаты обработки приведены в таблице - опыт 4) в количестве 900 м 3 из РВС-10000 циркулировался центробежным насосом ЦНС-180-85 по схеме "РВС - насос - КСУ - РВС" в течение 16 ч. На прием центробежного насоса подавали дозировочными насосами деэмульгирующий состав, состоящий из углеводородного растворителя СНПХ-7р-8 (смесь легкой пиролизной смолы и гексановой фракции) в объеме 6 м 3 (4500 кг); анионогенный ПАВ - сульфонол-40 (смесь натриевых солей алкилбензолсульфокислот с алкильным остатком, с содержанием в радикале 8-12 атомов углерода) в объеме 300 л (315 кг); неионогенного деэмульгатора Сепарол WF-34 (Германия) в объеме 200 л (180 кг), соотношение компонентов состава по массе соответственно 25:1,75:1. По завершении циркуляции эмульсию оставили на отстой, после 5 сут отстоя в РВС осталось 40 м 3 эмульсии. Т.о. было разрушено 860 м 3 или 95,5% промежуточного эмульсионного слоя и подготовлена нефть II группы качества. Контроль за процессом разрушения вели по остаточному содержанию воды, хлористых солей и механических примесей в нефти. Производительность насоса 180 м 3 /ч, кратность циркуляции равна 2,3. П р и м е р 2. Промежуточный слой в количестве 6500 м 3 (опыт 10) циркулировали насосом ЦНС-180-85 в течение 36 ч по схеме "РВС - насос - КСУ - РВС". На прием насоса подавали углеводородный растворитель СНПХ-7р-8 в количестве 6 м 3 с нормой расхода около 1000 г/м 3 , сульфонол - 3000 г/м 3 и дипроксамин - 157-65М (азотсодержащий блокосополимер окисей этилена и пропилена на основе этилендиамина (молекулярная масса - 5000) - 50 г/м 3 . Соотношение реагентов по массе соответственно 20:60:1. После однократной циркуляции эмульсию оставили на отстой. После 5 сут отстоя в РВС осталось 500 м 3 эмульсии. Т.о. было разрушено 6 тыс.м 3 эмульсии или 92% от отработанной и подготовлена нефть I группы качества. Производительность насоса 180 м 3 /ч, кратность циркуляции равна 1. Полученные результаты представлены в таблице, из которой видно, что показатели качества выделенной нефти соответствуют I-III группам по ГОСТ 9965-76.

Формула изобретения

СПОСОБ РАЗРУШЕНИЯ ПРОМЕЖУТОЧНОГО ЭМУЛЬСИОННОГО СЛОЯ, образующегося в процессе добычи и подготовки нефти путем обработки деэмульгатором и перекачки промежуточного слоя под слой воды по замкнутому циклу с последующим отстоем, отличающийся тем, что в качестве деэмульгатора используют состав, содержащий неионогенный деэмульгатор на основе блоксополимеров окисей этилена и пропилена, анионоактивный реагент на основе алкилбензолсульфоната натрия и растворитель на основе ароматических углеводородов при массовом соотношении компонентов в составе соответственно 1: 1,75 - 60: 20 - 25.

Перечислим основные достоинства ПО ПС, существенные для обеспечения высокой доступности.

ПО ПС уменьшает сложность создания распределенных систем. Подобное ПО берет на себя часть функций, которые в локальном случае выполняют операционные системы;
ПО ПС берет на себя маршрутизацию запросов , позволяя тем самым обеспечить "живучесть" прозрачным для пользователей образом;
ПО ПС осуществляет балансировку загрузки вычислительных мощностей, что также способствует повышению доступности данных;
ПО ПС в состоянии осуществлять тиражирование любой информации, а не только содержимого баз данных. Следовательно, любое приложение можно сделать устойчивым к отказам серверов;
ПО ПС в состоянии отслеживать состояние приложений и при необходимости тиражировать и перезапускать программы, что гарантирует "живучесть" программных систем;
ПО ПС дает возможность прозрачным для пользователей образом выполнять переконфигурирование (и, в частности, наращивание ) серверных компонентов, что позволяет масштабировать систему, сохраняя инвестиции в прикладные системы. Стабильность прикладных систем – важный фактор повышения доступности данных.

Обеспечение обслуживаемости

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

Динамическое переконфигурирование преследует две основные цели:

изоляция отказавших компонентов ;
сохранение работоспособности сервисов .

Лекция: Туннелирование и управление

Туннелирование

На наш взгляд, туннелирование следует рассматривать как самостоятельный сервис безопасности. Его суть состоит в том, чтобы "упаковать" передаваемую порцию данных, вместе со служебными полями, в новый "конверт". В качестве синонимов термина "туннелирование" могут использоваться "конвертование" и "обертывание".

Туннелирование может применяться для нескольких целей:

передачи через сеть пакетов, принадлежащих протоколу, который в данной сети не поддерживается (например, передача пакетов IPv6 через старые сети, поддерживающие только IPv4);
обеспечения слабой формы конфиденциальности (в первую очередь конфиденциальности трафика) за счет сокрытия истинных адресов и другой служебной информации;
обеспечения конфиденциальности и целостности передаваемых данных при использовании вместе с криптографическими сервисами.

Туннелирование может применяться как на сетевом, так и на прикладном уровнях. Например, стандартизовано туннелирование для IP и двойное конвертование для почты X.400.

На рис. 14.1 показан пример обертывания пакетов IPv6 в формат IPv4.

Рис. 14.1. Обертывание пакетов IPv6 в формат IPv4 с целью их туннелирования через сети IPv4.

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

Рис. 14.2. Межсетевые экраны как точки реализации сервиса виртуальных частных сетей.

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

Концами туннелей, помимо корпоративных межсетевых экранов, могут быть мобильные компьютеры сотрудников (точнее, их персональные МЭ).

Управление

Основные понятия

Управление можно отнести к числу инфраструктурных сервисов, обеспечивающих нормальную работу компонентов и средств безопасности. Сложность современных систем такова, что без правильно организованного управления они постепенно деградируют как в плане эффективности, так и в плане защищенности.

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

Согласно стандарту X.700, управление подразделяется на:

мониторинг компонентов;
контроль (то есть выдачу и реализацию управляющих воздействий);
координацию работы компонентов системы.

Системы управления должны:

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

Иными словами, управление должно обладать достаточно богатой функциональностью, быть результативным, гибким и информационно безопасным.

В X.700 выделяется пять функциональных областей управления:

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

В стандартах семейства X.700 описывается модель управления, способная обеспечить достижение поставленных целей. Вводится понятие управляемого объекта как совокупности характеристик компонента системы, важных с точки зрения управления. К таким характеристикам относятся:

атрибуты объекта ;
допустимые операции ;
извещения , которые объект может генерировать;
связи с другими управляемыми объектами.

Согласно рекомендациям X.701, системы управления распределенными ИС строятся в архитектуре менеджер/агент . Агент (как программная модель управляемого объекта) выполняет управляющие действия и порождает (при возникновении определенных событий) извещения от его имени. В свою очередь, менеджер выдает агентам команды на управляющие воздействия и получает извещения.

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

Логически связанной с многоуровневой архитектурой является концепция доверенного (или делегированного ) управления . При доверенном управлении менеджер промежуточного уровня может управлять объектами, использующими собственные протоколы, в то время как "наверху" опираются исключительно на стандартные средства.

Обязательным элементом при любом числе архитектурных уровней является управляющая консоль .

С точки зрения изучения возможностей систем управления следует учитывать разделение, введенное в X.701. Управление подразделяется на следующие аспекты:

информационный (атрибуты, операции и извещения управляемых объектов);
функциональный (управляющие действия и необходимая для них информация);
коммуникационный (обмен управляющей информацией);
организационный (разбиение на области управления).

Ключевую роль играет модель управляющей информации . Она описывается рекомендациями X.720. Модель является объектно-ориентированной с поддержкой инкапсуляции и наследования. Дополнительно вводится понятие пакета как совокупности атрибутов, операций, извещений и соответствующего поведения.

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

К числу концептуально важных можно отнести понятие "проактивного" , то есть упреждающего управления . Упреждающее управление основано на предсказании поведения системы на основе текущих данных и ранее накопленной информации. Простейший пример подобного управления – выдача сигнала о возможных проблемах с диском после серии программно-нейтрализуемых ошибок чтения/записи. В более сложном случае определенный характер рабочей нагрузки и действий пользователей может предшествовать резкому замедлению работы системы; адекватным управляющим воздействием могло бы стать понижение приоритетов некоторых заданий и извещение администратора о приближении кризиса.

Сейчас проявляется большой интерес к средствам промежуточного (межплатформного) программного обеспечения (middleware). Рынок этих продуктов рос в последнее время экспоненциально, и в ближайшие годы такая тенденция сохранится.

Главной задачей ПО промежуточного слоя (ПОПС) является согласование интерфейсов программ и устройств, Практически оно позволяет упростить процесс взаимодействия приложений друг с другом или с ресурсами и выполняет две функции:

– облегчение доступа приложений к ресурсам;

– ускорение процессов взаимодействия.

В промежуточном слое могут находится программы двух типов – услуги и объекты. Каждая из услуг выполняет конкретную простую функцию.

Промежуточный слой располагается между прикладным управлением и прикладными процессами, между этими процессами либо между операционной системой и прикладными процессами. К нему относят следующие средства (см. рис. 5.6).

Рисунок 5.6 – Классификация средств middleware

ПОПС, ориентированное на работу с серверами БД , предоставляет API для доступа к локальным или удаленным базам и скрывают особенности ОС и локальность базы данных. К этому типу ПОПС относятся средства реализации спецификаций ODBC, OLE DB, JDBC (Java Object Database Connectivity).

Мониторы транзакций оптимизируют работу системы, располагаются между клиентом и сервером БД и являются вторым уровнем трехзвенной архитектуры клиент-сервер. Клиентское приложение инициирует транзакцию в мониторе, который при необходимости запускает транзакцию базы данных, получает результат и перенаправляет его обратно клиентскому приложению. Наиболее популярными мониторами транзакций являются Microsoft Transaction Server, Tuxedo (BEA Systems), CICS (IBM), Encina (Transarc) и др.

Средства удаленного вызова процедур (RPC, Remots Procedure Call) предназначены для выделения части создаваемого приложения для выполнения на удаленной машине, организации вызова удаленного метода программы так, как если бы программный код находился на локальной машине. Код RPC «присоединяется» источнику и приемнику, осуществляет необходимые преобразования данных и запускает подпрограммы передачи данных по сети. RPC стали удобным механизмом для взаимодействия приложений на различных программно-аппаратных платформах. Распространенность языка программирования Java привела к созданию аналога RPC для Java-приложений – RMI (Remote Method Invocation).

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

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

В настоящее время основную долю рынка MOM занимают продукты IBM MQSeries и Microsoft MSMQ. IBM

ORB (Object Request Broker) – брокеры объектных запросов – наиболее бурно развивающийся тип middleware, управляют обменом сообщениями в сети, принимают запросы от клиента (клиентского приложения), осуществляяют поиск и активизацию удаленных объектов, которые принципиально могут ответить на запрос, и передают ответ объектам запрашивающего приложения. ORB, как и RPC и MOM, скрывает от пользователя процесс доступа к удаленным объектам. ORB поддерживает объектную модель, ставшую де-факто стандартом при разработке больших информационных систем. В настоящее время на рынке конкурируют стандарт CORBA и технология COM корпорации Microsoft.

MOM и ORB являются наиболее универсальными средствами middleware и могут применяться в большинстве случаев для организации связи между приложениями.

Прикладные программы, написанные на языке, не зависимом от платформ, сами могут служить промежуточным слоем.

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

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

Тема 6. Системы искусственного интеллекта

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

Можно сказать, что промежуточное ПО - наиболее важная часть среды клиент-сервер, поскольку если оно не работает правильно, ничего не будет работать вообще. В то же время этот вид программного обеспечения представляется весьма “темным местом”. В связи с этим давайте рассмотрим вопросы, которые можно считать основными: как выбрать промежуточное ПО, в каких случаях его использовать и что с его помощью можно делать.

Ориентация в новом мире

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

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

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

Обычно программисты пишут основной код приложения отдельно от той его части, которая взаимодействует с промежуточным ПО, а при написании этой части обычно используется API промежуточного ПО. Такое разбиение идеально подходит для распределенной среды клиент-сервер, где данные могут находиться на любой серверной платформе - от сервера Novell или Unix до мэйнфрейма IBM.

Реальность

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

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

В общих чертах процесс может выглядеть так:

Формулировка задачи (например, сокращение затрат и временных циклов в целях повышения конкурентоспособности);

Определение пути достижения цели (внедрение системы, более быстродействующей и гибкой по сравнению с существующей);

Поиск приложений, которые будут работать в новой среде;

Подбор соответствующего промежуточного программного обеспечения.

Выбор ПО промежуточного слоя

На рынке промежуточного ПО можно выделить шесть основных (очень разных) типов продуктов: промежуточное ПО баз данных, промежуточное ПО удаленных вызовов процедур, промежуточное ПО передачи сообщений, брокеры объектных запросов, мониторы обработки транзакций и специально разработанное ПО.

Промежуточное ПО баз данных, как и следует из его названия, имеет ограниченное применение. В клиентской части большинства систем клиент-сервер, как правило, есть приложение, которое обращается к данным в БД сервера. Если оно предназначено для использования только одного типа БД, например Oracle, то это наверняка останется неизменным, и тогда хорошим решением будет промежуточное ПО баз данных Oracle. Данный пример характерен для большинства реляционных БД и соответствующей технологии промежуточного ПО. Шлюзы БД обычно имеют системы промежуточного ПО БД, которые производят трансляцию между различными вариантами баз данных SQL или между SQL и не-SQL. Такие шлюзы воплощают скорее технологию трансляции, нежели технологию промежуточного ПО.

Промежуточное ПО удаленных вызовов процедур (RPC, Remote Procedure Calls) основано на более общем подходе к клиент-серверным вычислениям.

Разработчики приложений применяют RPC для доступа к данным на удаленном сервере аналогично вызову функции доступа к локальной БД.

Эта базовая концепция RPC используется в большинстве других технологий промежуточного ПО. С помощью RPC также можно передавать программное управление на удаленный сервер. Промежуточное ПО удаленных вызовов процедур, такое, как DCE (Distributed Computing Environment), предложенное OSF (Open Software Foundation), по существу производит поиск сервера базы данных в сети.

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

Вместе с тем подход, основанный на RPC, имеет одну особенность: после осуществления удаленного вызова клиентская система обычно ждет ответа сервера на запрос. Любой сбой на пути запроса блокирует клиентское приложение.

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

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

Объектное промежуточное ПО представлено брокерами объектных запросов (ORB, Object Request Brokers). Эта технология пропагандировалась как единственный путь, позволяющий привнести преимущества объектной технологии в распределенные вычисления. Брокеры объектных запросов управляют объектами, которые ведут себя практически так же, как RPC.Однако распределенные объекты могут содержать гораздо более сложную информацию о распределенном запросе или службе, чем RPC или большинство сообщений, они могут работать и с неструктурированными или нереляционными данными. Брокеры объектных запросов, соответствующие стандарту общей архитектуры брокера объектных запросов CORBA (Common Object Request Broker Architecture) поддерживают язык описания интерфейса IDL (Interface Definition Language), который в процессе пересылки объектов по сети работает как API промежуточного ПО.

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

Как промежуточное ПО мониторы обработки транзакций обеспечивают единый API для написания распределенных приложений. Обладая полным набором инструментов управления, эти системы управляют распределенной средой подобно системам, основанным на мэйнфреймах.

Специально разработанное ПО. Многие инструменты разработки систем клиент-сервер и широкомасштабные приложения клиент-сервер имеют свою технологию промежуточного ПО. Такие специальные системы, как, например, промежуточное ПО R/3 BASIS компании SAP, оптимизированы для конкретного инструмента разработки или приложения. Они обычно работают хорошо, но адаптировать их к существующей клиент-серверной среде, средствам разработки и другим приложениям довольно сложно.

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

Возможно, в сложной среде клиент-сервер придется применить не один подход к организации промежуточного слоя: даже отдельное приложение в принципе может использовать RPC для доступа к реляционной БД, систему сообщений для управления транзакциями на мэйнфрейме и ORB - для управления объектами. Многие системы промежуточного слоя могут взаимодействовать друг с другом. Однако надо иметь в виду, что при совместном использовании нескольких продуктов промежуточного ПО возникает проблема дополнительного администрирования, совместимости различных API и взаимодействия служб.