Исследование проблем интеграции в распределенных системах унаследованных приложений с использованием асинхронного пи-исчисления

Брейман Александр Давидович; Зерний Андрей Юрьевич; Казьмин Борис Викторович

системный анализ X

УДК 004.413

исследование проблем интеграции в распределенных системах унаследованных приложений с использованием асинхронного пи-исчисления

А. Д. Брейман,

канд. техн. наук, доцент А. Ю. Зерний, аспирант Б. В. Казьмин,

аспирант

Московский государственный университет приборостроения и информатики

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

Ключевые слова — интеграция приложений, промежуточное программное обеспечение, асинхронное пи-исчисление.

Введение

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

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

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

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

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

Требования к архитектуре

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

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

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

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

4) адаптер клиента должен минимально необходимо расширять функционал клиента;

5) взаимодействие «клиент — клиент» должно поддерживать все возможные модели связывания.

Интеграция на уровне приложения [2, 3] в рамках рассматриваемой архитектуры является исключительным случаем и требует подробного исследования. Отметим, что такая архитектура подразумевает связывание не приспособленных для того клиентов, комбинирование продиктованных их природой связей при необходимости соблюдать условия, накладываемые особенностями исследуемой области. На этом уровне интеграции возникают проблемы во взаимодействии друг с другом приложений, ориентированных на разные типы связи. Для того чтобы исследовать возможность устранения блокировок, которые, как будет показано далее, возникают между разносвязанными приложениями, необходимо рассмотреть используемые типы связи и построить математическую модель системы на основе таких типов.

Классификация типов связи

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

1) сохранная асинхронная связь;

2) сохранная синхронная связь;

3) нерезидентная асинхронная связь;

4) нерезидентная синхронная связь с синхронизацией по приему;

5) нерезидентная синхронная связь с синхронизацией по доставке;

6) нерезидентная синхронная связь с синхронизацией по ответу.

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

Исследование сочетаний типов связи

Для исследования поведения взаимодействующих приложений предлагается использовать асинхронное пи-исчисление [5-7]. В статье [8] представлено формализованное описание процессов, отражающих приведенные в работе [4] типы связи, а также показано, что из 36 возможных сочетаний типов связи 12 сочетаний приводят к блокировке работы системы. В качестве примера возьмем пару типов связи, на основе которой, как будет показано далее, можно продемонстрировать вариант взаимодействия с блокировкой процессов.

Введем:

тАС — сообщение, отправителем которого является процесс А, а получателем — процесс С;

тСА

ссылка на пр°цесс Сарр.те88.

Отправитель (нерезидентная синхронная связь с синхронизацией по ответу)

А = (V тАСи) х

х (хи | ии.(итАс | итсА ^mcAS^mcAS^A;)),

где А = тА, — процесс, следующий за синхронизацией взаимодействия.

Получатель (нерезидентная синхронная связь с синхронизацией по доставке)

С = {жт){сарр |

Capp.Ьuff 1 Capp.mess )>

где Сарр^ — процесс буфера; Сарр.те88 — процесс счетчика состояния получателя; Сарр — процесс

получателя; С' — процесс, предшествующий обработке сообщения; С" — процесс, следующий за обработкой сообщения:

Сарр.ЪиП = ли.(Уи)х х (ии | vmAc■(yd)(cd | de.(emAc | df.eu)));

Capp.mess

(vqs)(\mp.(р^ |qs));

Сарр = С '^.(уе)(^ | етАс .(чр)х х (тр | pq. (^)^) | еи.щ) | Тс .С"));

С = тс>; С" = тс"■

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

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

В = хи.(т)(ии |итАС.((vd)х х yd | de. (етАС | dmCA .итСА))).

В результате процесс системы будет состоять из трех параллельных процессов:

й = (Vху)(А | В | С);

Б ^ (vxyuvmACqs)(qs.А' | (vcdefmp)х х (С’’ 10 10 |!тр.(щ | qs))) =

= С" | (vqspm)(qs.A' | !тр.(щ | qs)) ~ ~^)^.А')|С '' = Б' ~С' ;

(х, у, и, V, тАС, q, в) £ ^(А');

(х, у, и, V, тАС, q, s, с, d, е, f, т, р) £ ПС11).

Блокировка: процессу А для продолжения работы (перехода к процессу А ) необходима синхронизация по q е Ьп^'); одновременно процесс C продолжает работу (процесс C//), при этом q й й fn(C"). Процесс S' сильно конгруэнтен процессу С (существует отношение сильной бисимуляции [9] между процессами S' и C"), вследствие чего процесс А недостижим.

Устранение блокировок

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

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

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

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

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

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

что такое связывание приводит к блокировке отправителя.

Отправителю, процессу А, для продолжения работы (перехода к процессу А ) необходима синхронизация по q е Ьп^'); одновременно получатель, процесс C, продолжает работу (процесс C"), при этом q й fn(C"). Процесс А', продолжение работы отправителя, недостижим.

Рассмотрим состояние системы, предшествующее синхронизации процесса C с процессом B:

5 = ^ху)( А\В\С) ^

^ (vu)(umcA ^mcAS^mcAS^A' \ (vd)х х ^тсА.итсА \ (vqmps)(dq\Tc■C"\qs\\mp.(щ\qs)))) =

= 5! ^ (vqs)(qs. А' \С " \^тр)(!тр.( pq\ qs))) = 5' .

Процесс S1 — система S в состоянии, предшествующем синхронизации процесса C с процессом B. Процесс S' — система S в заключительном состоянии. Процесс А недостижим.

Процессу А для продолжения работы (перехода к процессу А ) необходима синхронизация по q е Ьn(S'). Пусть S" = S1. Расширим S" так, чтобы обеспечивалась необходимая синхронизация:

= итСА .mCAS.mCAS.A1;

В-1 = йтСА-итСА; С = Тс .С".

Необходимую синхронизацию А1 может обеспечить только процесс B1. Расширим B1 необходимым поведением:

В = <1тсА ■ (утсА )(итсА | mcAS | mcAs)■

Обеспечиваемая расширенным процессом B1 синхронизация должна происходить после завершения обработки запроса процессом C1. Добавим в процесс B1 ожидание сообщения о достижении процессом C1 необходимого состояния:

В = dmCA. mCAS.mCAS.(ymCA) х

х (итСА | mcAS | mcAs).

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

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

С = тс .тр\с').

Подставим в S" процесс Б’1 вместо B1 и процесс C1 вместо C1:

Б"' = (уи)(итСА .mCAS.mCAS.А | (vd) х

х (В/ |(vqmps)(dq | С{ | qs \!тр.(щ | qs)))) ^

^ А | С '

(х, у, и, V, тАС, 1, в) £ ^(А0;

(х, у, и, V, тАс, 1, с, d, е, f, т, р) £ ЩС").

Процесс S"' (процесс S" с измененным поведением) не имеет блокировок. Расширим процесс Б в соответствии с В'{:

Расширим процесс Capp в соответствии с C1:

^Ыа1 = {^хУ){А \ В' | {жт)х

х {Сарр 1 Capp.buff 1 Capp.mess )) ^ А \С ;

(х, у, и, V, тАс, 1, в) £ МА');

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

(х, у, и, V, тАс, Ц, S, с, d, е, f, т, р) £ ЩС").

Система Sfinal не имеет блокировок. Проблема синхронизации решена расширением поведения посредника (Б'1) и минимальным расширением поведения получателя (^). Аналогичным образом с помощью предложенного подхода решаются выявленные блокировки возможных сочетаний типов связи [8].

Заключение

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

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

Литература

1. Гофф М. К. Сетевые распределенные вычисления. Достижения и проблемы. М.: Кудиц-Образ, 2005. — 320 с.

2. Ладыженский Г. Интеграция приложений такая, как она есть // Открытые Системы. 2006. № 9. http://www.osp.ru/os/2006/09/3776484/.

3. Хоп Г., Вульф Б. Шаблоны интеграции корпоративных приложений: Проектирование, создание и развертывание решений, основанных на обмене сообщениями. — М.: Вильямс, 2007. — 672 с.

4. Таненбаум Э. С., Ван Стеен М. Распределенные системы. Принципы и парадигмы. — СПб.: Питер, 2003. — 877 с.

5. Milner R. Communicating and mobile systems: the pi-calculus. — Cambridge: Cambridge University Press, 1999. — 161 p.

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

6. Boudol G. Asynchrony and the pi-calculus: Research Report 1702 / INRIA. — Sophia-Antipolis, 1992. — 11 p.

7. Honda K., Tokoro M. An object calculus for asynchronous communication // Proc. of ECOOP'91. Geneve, 1991. Р. 133-147.

8. Брейман А. Д., Зерний А. Ю., Казьмин Б. В. Использование асинхронного пи-исчисления для исследования моделей связи при решении задач организации распределенных систем // Вестник МГУПИ. М.: МГУПИ, 2009. С. 57- 63.

9. Amadio R. M., Castellani I., Sangiorgi D. On Bisimulations for the Asynchronous pi-сalculus // Theoretical Computer Science. 1998. Vol. 195. N 2. Р. 291324.

Researching the problems of legacy application integration in distributed systems using asynchronous picalculus

Текст научной работы на тему «Исследование проблем интеграции в распределенных системах унаследованных приложений с использованием асинхронного пи-исчисления»