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

Формула / Реферат | Похожие патенты | МПК / Метки | Текст | Код ссылки

Номер патента: 6307

Опубликовано: 27.10.2005

Авторы: Трекин Николай Евгеньевич, Крайнов Евгений Викторович, Сивенцев Алексей Анатольевич, Токовенко Сергей Витальевич, Игошин Юрий Сергеевич

Скачать PDF файл.

Формула / Реферат

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

сетевые средства для осуществления обмена данными в сети,

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

логические средства, выполненные с возможностью

организации одного или более буферов для сообщений в запоминающем устройстве,

определения адреса приложения-отправителя из принятого от локального отправителя сообщения,

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

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

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

3. Информационный коммутатор по п.1, в котором структура данных представляет собой локальную таблицу коммутации.

4. Информационный коммутатор по п.2, в котором сообщение представляет собой пакет, называемый сообщением протокола информационного обмена (ПИОС), причем тело этого пакета содержит данные приложения-отправителя, а структура тела этого пакета соответствует одному из набора протоколов информационного обмена (ПИО), а запрос является пакетом управления передачей сообщения (ПУПС), называемым ПУПС-запросом, который содержит запрос приложения-получателя на получение ПИОС.

5. Информационный коммутатор по п.4, который помимо пакетов типа ПИОС и ПУПС-запроса оперирует пакетами, по меньшей мере, следующих типов:

ПУПС-квитанция, представляющий собой ПУПС, отправляемый информационным коммутатором приложению-отправителю и содержащий подтверждение доставки ПИОС всем приложениям-получателям;

ПУПС-запрос квитанции, представляющий собой ПУПС, содержащий запрос приложения-отправителя на выдачу подтверждения о доставке ПИОС всем приложениям-получателям;

ПУПС-ответ, представляющий собой ПУПС, посылаемый информационным коммутатором в ответ на ПИОС или ПУПС-квитанцию,

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

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

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

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

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

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

11. Информационный коммутатор по п.2, в котором каждый адрес приложения-отправителя содержит уникальный идентификатор приложения-отправителя и идентификатор порта протокола информационного обмена (ПИО-порта) приложения-отправителя, а адрес локального получателя содержит уникальный идентификатор локального получателя и ПИО-порт локального получателя.

12. Информационный коммутатор по п.11, в котором в случае, если локальным получателем является другой информационный коммутатор, то ПИО-порт локального получателя игнорируется при обработке принятого сообщения.

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

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

15. Информационный коммутатор по п.14, в котором по меньшей мере одним локальным получателем является приложение-получатель, при этом для каждого приложения-получателя

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

отправка сообщения приложению-получателю из локального буфера осуществляется после приема запроса от приложения-получателя.

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

17. Информационный коммутатор по п.14, в котором по меньшей мере одним локальным получателем является другой информационный коммутатор, при этом для каждого другого информационного коммутатора

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

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

18. Информационный коммутатор по п.1, в котором сетевые средства осуществляют обмен данными по сети согласно стеку протоколов TCP/IP.

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

устройство обработки данных для исполнения упомянутых машиноисполняемых команд.

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

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

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

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

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

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

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

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

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

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

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

модуль синхронизации, предназначенный для обеспечения синхронизации хранилища данных;

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

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

при этом способ содержит этапы, на которых

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

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

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

отправляют буферизованное сообщение по меньшей мере одному локальному получателю.

29. Способ по п.28, в котором локальным отправителем является либо приложение-отправитель, либо другой информационный коммутатор, а локальным получателем является либо приложение-получатель, либо другой информационный коммутатор.

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

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

32. Способ по п.31, в котором по меньшей мере одним локальным получателем является приложение-получатель, при этом для каждого приложения-получателя

помещают принятое сообщение в буфер, соответствующий приложению-получателю,

принимают и обрабатывают запрос от приложения-получателя на получение сообщения,

отправляют буферизованное сообщение приложению-получателю.

33. Способ по п.32, в котором на время выполнения передачи сообщения приложению-получателю выполняют блокирование буфера на чтение приложением-получателем.

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

помещают принятое сообщение в буфер, соответствующий другому информационному коммутатору,

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

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

первый информационный коммутатор по п.26, находящийся в активном состоянии, в котором выполняется коммутация, и

второй информационный коммутатор по п.27, находящийся в неактивном состоянии,

при этом первый и второй информационные коммутаторы в любой момент времени обеспечивают синхронизацию своих хранилищ данных посредством своих модулей синхронизации,

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

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

37. Отказоустойчивый узел коммутации по п.35, который поддерживает следующие режимы функционирования:

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

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

переключение на резерв, при котором осуществляется перевод второго информационного коммутатора в активное состояние при отказе первого информационного коммутатора;

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

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

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

39. Отказоустойчивый узел коммутации по п.37, в котором в рабочем режиме с инкрементальной синхронизацией

первый информационный коммутатор находится в активном состоянии, а второй информационный коммутатор находится в неактивном состоянии;

модуль синхронизации первого информационного коммутатора принимает запросы от всех компонентов первюую информационного коммутатора на изменение данных и осуществляет посылку этих запросов хранилищу данных первого информационного коммутатора и соответствующих команд репликации модулю синхронизации второго информационного коммутатора;

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

модуль мониторинга первого информационного коммутатора через заранее заданный временной интервал периодически посылает контрольный сигнал модулю переключения на резерв второго информационного коммутатора;

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

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

41. Отказоустойчивый узел коммутации по п.37, в котором в режиме переключения на резерв

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

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

42. Отказоустойчивый узел коммутации по п.40, в котором после восстановления отказавшего первого информационного коммутатора отказоустойчивый узел коммутации переводится в режим полной динамической синхронизации, при котором на втором информационном коммутаторе

сбрасываются флаги синхронизации у всех записей таблиц хранилища данных;

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

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

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

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

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

T = 3Ч D/V_max,

где D - объем хранилища данных, байт;

V_max - максимальная производительность информационного коммутатора по приему сообщений, байт/с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

присвоения упомянутому приложению идентификатора первого типа;

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

обеспечения обмена сообщениями между упомянутым приложением и сетью ИК.

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

присвоения упомянутому приложению идентификатора первого типа;

обеспечения обмена сообщениями между упомянутым приложением и сетью ИК.

60. Система по п.58 или 59, в которой каждый ИК-стек из упомянутого их множества при обеспечении обмена сообщениями между соответствующим ему приложением и сетью ИК

добавляет к полученному от упомянутого приложения сообщению упомянутый идентификатор первого типа и соответствующий этому сообщению идентификатор второго типа и передает это сообщение в сеть ИК;

принимает сообщения из сети ИК и предоставляет их упомянутому приложению;

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

61. Система по п.60, в которой при добавлении идентификаторов к сообщению упомянутый ИК-стек присоединяет к этому сообщению заголовок и вносит упомянутые идентификатор первого типа и соответствующий сообщению идентификатор второго типа в соответствующие поля этого заголовка.

62. Система по п.58 или 59, в которой идентификатором первого типа является идентификатор приложения, а идентификатором второго типа является идентификатор порта протокола информационного обмена (ПИО-порт).

63. Система по п.60, в которой упомянутый ИК-стек дополнительно выполнен с возможностью задания либо блокируемого режима передачи сообщения, либо неблокируемого режима передачи сообщения, причем при задании режима передачи упомянутый ИК-стек заносит метку режима передачи в соответствующее поле заголовка сообщения.

64. Система по п.63, в которой упомянутый ИК-стек дополнительно выполнен с возможностью буферизации передаваемых и принимаемых сообщений.

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

66. Система по п.60, в которой упомянутый ИК-стек представляет собой объект программного обеспечения.

67. Система по п.66, в которой упомянутый ИК-стек является частью упомянутого приложения.

68. Система по п.66, в которой упомянутый ИК-стек является программной библиотекой, подключаемой к упомянутому приложению.

69. Система по п.65, в которой упомянутый ИК-стек представляет собой элемент аппаратных средств.

70. Способ организации взаимодействия между множеством распределенных приложений, реализуемый системой интеграции приложений по п.58 и содержащий этапы на которых

ИК-стек, соответствующий приложению-отправителю, выполняет обработку полученного от приложения-отправителя сообщения, добавляя при этом к сообщению адрес приложения-отправителя, и пересылает обработанное сообщение в сеть ИК;

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

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

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

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

71. Способ по п.70, в котором сеть ИК принимает пересланное ИК-стеком сообщение посредством информационного коммутатора, для которого упомянутое приложение-отправитель является локальным отправителем, причем в каждом из упомянутого по меньшей мере одного маршрута упомянутый информационный коммутатор является первым,

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

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

72. Способ управления взаимодействием между множеством распределенных приложений, реализуемый системой интеграции приложений по п.59 и содержащий этап, на котором

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

73. Способ по п.72, в котором изменение взаимодействия представляет собой добавление нового взаимодействия, при этом при модификации структуры данных из состава конфигурационных данных сети ИК добавляют в упомянутую структуру данных одну или более новых записей, определяющих упомянутое новое взаимодействие и содержащих адреса упомянутых двух или более приложений.

74. Способ по п.72, в котором изменение взаимодействия представляет собой удаление существующего взаимодействия, при этом при модификации структуры данных из состава конфигурационных данных сети ИК удаляют из упомянутой структуры данных записи, содержащие адреса упомянутых двух или более приложений и определяющие упомянутое взаимодействие.

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

76. Способ по п.73, в котором при добавлении нового взаимодействия посредством системы управления

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

для каждой из упомянутых новых записей в упомянутой полной копии конфигурационных данных задают маршрут в сети ИК;

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

77. Способ по п.74, в котором при удалении взаимодействия посредством системы управления

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

для каждой из упомянутых одной или более записей в упомянутой полной копии конфигурационных данных определяют соответствующий этой записи маршрут в сети ИК;

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

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

Рисунок 1

Текст

Смотреть все

006307 Область техники, к которой относится изобретение Настоящее изобретение относится, в частности, к компьютерным системам и, более конкретно, к системе, способам и устройствам, предназначенным для обеспечения и управления взаимодействием между распределенными разнородными приложениями. Предшествующий уровень техники Увеличение количества информационного окружения, основанного на сетевом взаимодействии, и появление потребности в обслуживании запросов удаленных клиентов вызвало потребность в создании средств и технологий, обеспечивающих обслуживание и развитие такого информационного окружения. С появлением и широким распространением недорогих аппаратных сетевых средств практически каждый компьютер из используемых в настоящее время подключен к той или иной информационной сети. Очень часто информационные сети обеспечивают соединение компьютерных устройств, включающих в себя разнородные аппаратные платформы, операционные системы, сетевые протоколы и программные приложения. Более того, часто возникает необходимость совместного и согласованного использования разнородных программных приложений, распределенных по сети, для решения единой производственной или технологической задачи. Такие программные приложения могут быть реализованы в виде процессов единого программного приложения, выполняющихся на различных компьютерах, подключенных к информационной сети. Использование распределенных программных приложений позволяет наиболее эффективно использовать вычислительные ресурсы, но возникают дополнительные сложности в написании таких распределенных программ по сравнению с написанием централизованных программных приложений. При создании распределенных программных приложений разработчику приходится задумываться не только о собственно прикладной части программ, но и о таких составляющих как асинхронность приема данных, разнообразие протоколов передачи, целостность и очередность передаваемых данных,буферизация поступающих данных, и других проблемах, связанных с передачей данных между независимыми частями одного распределенного приложения. В результате, для того чтобы проводить развитие и управление распределенными программными приложениями, обычно приходится затрачивать большие финансовые средства не только на разнообразные программные инструменты, но и на содержание большого количества специалистов, разбирающихся в низкоуровневых особенностях различных операционных систем и сетевых протоколов. Это также приводит к гораздо большим затратам времени на реализацию технических изменений распределенного приложения, чем на собственно улучшение его потребительских качеств. В настоящее время для организации обмена разнородными данными между программными приложениями в компьютерных системах применяют различные способы с использованием сетевых устройств. Обычно, организации (например, коммерческому предприятию) для выполнения множества производственных задач приходится использовать различные сетевые программные приложения. Например,предприятие может содержать в своем составе отдельную компьютерную систему со специализированным программным обеспечением для обеспечения бухгалтерского учета (бухгалтерия), другую систему со специализированным программным обеспечением для управления поступающими заявками (отдел сбыта) и третью компьютерную систему, обеспечивающую функционирование удаленных складов при помощи своего специализированного программного обеспечения. В некоторых ситуациях организация может нуждаться в обмене данными между такими специализированными компьютерными системами. Так например, отдел сбыта должен получить информацию о достаточности количества товаров со складов и информацию о подтверждении покупательских платежей из бухгалтерии. Склады, в свою очередь,ждут от отдела сбыта указаний об отгрузке определенного количества товаров. Однако, зачастую форматы данных, включенных в программные приложения этих специализированных систем, могут существенно различаться, что может повлечь за собой определенные трудности или невозможность непосредственного обмена данными. Кроме того, при таком обмене данными бывает необходимо соблюдать определенную его очередность. Так например, только после подтверждения наличия необходимого количества товара на складе последует подготовка к оплате счета, и только после подтверждения оплаты счета последует указание об отгрузке. Одним из применяемых способов интеграции программных приложений предприятия является использование сетевых компьютерных устройств, на которых установлено программное обеспечение, выполняющее функции интеграции. Способы управления распределением разнотипных данных между компьютерами, подключенными в информационную сеть, включают в себя- способ распределения разнотипных данных с использованием отношений "клиент-сервер" и- способ, использующий специализированные процессы-маршрутизаторы. Способ распределения данных с использованием отношений "клиент-сервер" (см., например,http://niis.stekloholding.ru/oit/3.php), применяемый для минимизации сложности большинства существующих распределенных вычислительных приложений и средств, основан на модели общения "клиент-1 006307 сервер". Такая модель справляется с сетевой сложностью путем наложения в момент разработки приложений такого ограничения, которое допускает только одиночную связь между двумя процессами. Применение подобного ограничения иллюстрируется на фиг. 1, где к одному серверу подключены три клиента. Примером такого подключения может быть серверное устройство большой компании, содержащее складскую базу данных и базу данных заявок, к которым через информационную сеть подключено множество персональных компьютеров. Расширением указанного способа является так называемая технология middleware (см., например,http://www.citforum.ru/SE/middleware/), в которой выделяется дополнительное, третье звено, на которое возлагается выполнение вычислительных процессов, оставляя классическому "серверному" звену лишь роль хранилища данных. Клиент-серверная технология и технология middleware являются уже "классическими" и реализованы в таких широко известных системах как SAP R3, Oracle Business Suite и т.д. Развитием технологии "клиент-сервер" можно считать технологии, реализующие компонентные(объектные) распределенные системы, примерами реализации которых могут служить технологияCORBA (см, например, http://www.osp.ru/os/1999/03/06.htm) консорциума OMG, технология COM/DCOM компании Microsoft, технология RMI компании JavaSoft. Более сложный случай отношений "клиент-сервер" изображен на фиг. 2, где в таких отношениях участвуют три сервера, содержащие единую базу данных, и три клиента. Рассмотрение фиг. 1 и 2 открывает основные недостатки изложенного подхода и, следовательно,основывающихся на нем вышеупомянутых технологий. Так, в случае с одним сервером и тремя клиентами необходимо организовывать всего 3 информационные связи, а в случае добавления еще двух серверов происходит увеличение количества необходимых информационных связей до 11. Нетрудно заметить, что дальнейшее увеличение количества клиентов и серверов приводит к экспоненциальному росту количества необходимых информационных связей. Возрастающая сложность информационных связей при развитии системы на практике может быть усугублена разнородностью операционных систем и сетевых протоколов, обеспечивающих функционирование элементов системы. Затраты на обслуживание и развитие в этом случае также возрастают с ростом такой разнородности. Следует добавить, что при такой реализации обмена данными отсутствует управляемость информационными связями программных приложений, так как само приложение должно определять наличие и направление информационной связи. Контроль за регламентом осуществления информационного обмена также затруднен и требует дополнительных программных средств. Другим путем управления распределением разнотипных данных между компьютерами, подключенными в информационную сеть, являются способ и система, использующие специализированные процессы-маршрутизаторы. Примером реализации таких систем могут служить системы, построенные на базе технологии обмена сообщениями, такие как система MQ Series Integrator компании IBM, система MSMQ компании Microsoft, система Rendevous компании TIBCO, система JMS (http://www.javaworld.com/javaworld/jw-102002/jw-1025-jmsp.html) компании Sun Microsystems и т.д. Например, для упрощения использования распределенных приложений, объединенных информационными сетями, предложена система управления распределением разнородных данных, которая обеспечивает функционирование "виртуальной" полносвязной сети во избежание чрезмерной нагрузки на реальную сеть (например, см. US 5634010). Такая система для распределения данных между различными процессами, расположенными на подключенных к сети компьютерах, использует принцип "концентрации данных". Принцип "концентрации данных" предполагает заключение разнородных данных, участвующих в обмене между приложениями, в единый пакет (объект), передаваемый внутри сообщения. Кроме собственно данных объект также содержит отметку реального времени, набор свойств и адресную информацию. В такой системе на каждом компьютере информационной сети, где запущены процессы приложения, также запускается основной элемент управления распределением данных - процесс-маршрутизатор(М), выполняющий функцию локальной маршрутизации объектов данных, передаваемых или принимаемых процессами приложений (см. фиг. 3). При этом, процессы приложений для обеспечения информационной связи объявляют соответствующему им локальному процессу-маршрутизатору свою заинтересованность в том или ином типе передаваемого или принимаемого объекта данных. Локальный процессмаршрутизатор (М) обменивается информацией о заинтересованности процессов приложений с удаленными процессами-маршрутизаторами, организуя тем самым указанную "виртуальную" сеть процессов приложений, заинтересованных в обмене объектами данных одного типа. Основные недостатки указанной системы управления распределением разнотипных данных связаны с тем, что реальные системы интеграции приложений обычно требуют не только обеспечения гибкости и масштабируемости, но также и синхронизации, контроля за регламентом осуществления информационной связи, а также мер информационной безопасности.-2 006307 При выполнении таких функций каждым процессом-маршрутизатором объем вычислительных ресурсов каждого компьютера сети, используемый для обеспечения указанных "неприкладных" (служебных) функций может стать сопоставимым с вычислительными ресурсами, занятыми процессами приложений. Кроме того, может стать неизбежным и неоптимальное (избыточное) использование вычислительных ресурсов информационной системы в целом, так как фактически произойдет дублирование служебных функций на всем множестве компьютеров, а согласованность выполнения таких служебных функций также потребует организации интегрирующего сетевого взаимодействия. При такой реализации обмена данными контроль за информационными связями программных приложений затруднен, поскольку наличие, формат данных и направление информационной связи определяется только "желанием" программного приложения и при этом информационная связь может возникнуть динамически. Одним из решений задачи интеграции разнородных программных приложений является применение специализированного серверного компьютера, на котором установлено интегрирующее программное обеспечение (см., например, US 2002120786). В таком применении в информационную сеть предприятия подключают серверный компьютер с интегрирующим программным обеспечением для предоставления ему возможности получать, преобразовывать и доставлять данные при обмене как между программными приложениями одного подразделения предприятия, так и разных его подразделений. Дополнительно серверный компьютер, выполняющий интегрирующую функцию, может также использоваться для автоматизации бизнес-процессов. В этом случае серверный компьютер определяет, какой именно информацией и в какой последовательности обмениваются различные системы, участвующие в этих бизнес-процессах. Использование для этих целей интегрирующего программного обеспечения обеспечивает дополнительную гибкость сетевому взаимодействию программных приложений предприятия. Основные недостатки данного способа с использованием специализированного серверного компьютера заключаются в следующем. Обычно программное обеспечение, автоматизирующее документооборот предприятия и предоставляющее возможность взаимного обмена между программными приложениями, требует применения мощного специализированного серверного компьютера. Обслуживание такого серверного устройства часто требует квалифицированного обслуживающего персонала для установки и сопровождения интегрирующего программного обеспечения, настройки серверного устройства на конкретную сеть предприятия. Также понятно, что стоимость такого технического решения может быть очень высока, так как для интеграции программных приложений предприятия используется не только специализированное интегрирующее программное обеспечение, но и специализированные аппаратные средства серверного компьютера. Проблема также усугубляется тем, что при достижении растущей информационной системой предприятия некоторого предела могут потребоваться значительные затраты на обновление аппаратуры серверного устройства. Кроме того, при превентивном повышении мощности такого серверного устройства,начальный этап эксплуатации информационной системы предприятия будет обладать меньшей эффективностью из-за "простаивания" вычислительных возможностей серверного устройства. Основываясь на приведенных доводах, можно сделать вывод, что масштабируемость такого технического решения оставляет желать лучшего. Интеграция разнородных программных приложений может выполняться с использованием типового сетевого устройства (см. US 20020120786 от 29.08.2002). При этом система интеграции программных приложений предприятия состоит из множества подключенных к информационной сети компьютеров, на которых выполняются интегрируемые программные приложения, и специализированного сетевого устройства, выполняющего собственно интегрирующую функцию. Сетевое устройство доступно конечным пользователям и системным администраторам через интерфейсы Web-страниц и совместимые интерфейсы конечных пользователей. Дополнительно, сетевое устройство доступно через сеть для проведения обновления и модернизации программного обеспечения, шаблонов интеграции программных приложений и профилактических мероприятий, поддерживающих его нормальное функционирование. Такое сетевое устройство используется для предоставления множества функций, необходимых при интеграции приложений предприятия. При этом обмен данными между приложениями происходит в соответствии с шаблонами интеграции, регламентирующими передачу информации от одного приложения-отправителя одному или нескольким приложениям-получателям. Пример подобного способа интеграции приложений иллюстрируется фиг. 4. Основные недостатки данного способа следующие. Несмотря на достаточную для интеграции распределенных приложений функциональность указанного устройства, подключение его к другой локальной сети, отличной от локальной сети интегрируемых приложений, может привести к недопустимому увеличению информационного трафика всей глобальной сети. Необходимость предоставления доступа к такому сетевому устройству из множества удаленных сетевых адресов (при необходимости связывания множества программных приложений, размещенных на удаленных компьютерах) может привести к уменьшению уровня безопасности.-3 006307 Шаблоны интеграции приложений регламентируют только передачу данных от одного отправителя нескольким получателям. В этом случае, при наличии приложения-получателя, заинтересованного в приеме данных от нескольких приложений-отправителей, контроль комплектности принимаемых данных является задачей приложения-получателя. При добавлении в шаблон интеграции нового приложения-получателя, воспринимающего данные в формате, отличном от уже используемых, требуется изменение информационного обеспечения сетевого устройства. Таким образом, из вышеизложенного следует, что в уровне техники имеется потребность в системе,которая бы обеспечивала интеграцию распределенных и, в общем случае, разнородных приложений посредством организации между ними взаимодействия таким образом, чтобы сами приложения были в максимальной степени изолированы от непосредственного участия в организации этого взаимодействия,что обеспечило бы должную гибкость и масштабируемость. Сущность изобретения Задачей настоящего изобретения является обеспечение интеграции распределенных разнородных приложений посредством организации взаимодействия между этими приложениями таким образом, чтобы детали и реализация этого взаимодействия, инициаторами которого являются приложения, были по максимуму отделены от самих приложений, что обеспечивает гибкость и масштабируемость при организации упомянутого взаимодействия и управлении им. Для решения этой задачи предложена система интеграции множества распределенных приложений,которая включает в себя сеть информационной коммутации и совокупность логических средствадаптеров, предназначенных для обеспечения взаимодействия этих приложений с сетью информационной коммутации. Каждое логическое средство-адаптер однозначно сопоставлено приложению из упомянутого множества распределенных приложений и, по существу, представляет подсистему этого приложения, обеспечивающую его совместимость с сетью информационной коммутации. Приложения, взаимодействующие между собой с помощью предложенной системы интеграции,непосредственно обмениваются данными только с соответствующими им адаптерами, при этом непосредственную реализацию этого взаимодействия полностью берет на себя сеть информационной коммутации, что обеспечивает изоляцию приложений от непосредственной организации взаимодействия. Таким образом, основным компонентом предложенной системы интеграции приложений является сеть информационной коммутации, называемая в материалах настоящей заявки также сетью коммутации сообщений, которая предназначена для организации взаимодействия распределенных программных приложений посредством коммутации пересылаемых между ними сообщений. Эта сеть содержит множество коммутационных устройств, выполненных с возможностью буферизации упомянутых сообщений и хранения данных, при этом упомянутое множество коммутационных устройств хранит конфигурационные данные сети информационной коммутации, включающие в себя определяющую взаимодействие между приложениями структуру данных, каждая запись которой содержит адрес приложения-отправителя и адрес приложения-получателя, причем в каждой записи адрес приложения-отправителя позволяет однозначно определить адрес приложения-получателя. Упомянутое множество коммутационных устройств выполняет коммутацию принятого от приложения-отправителя сообщения на основе определения по меньшей мере одного адреса приложения-получателя на основе заданного в упомянутом сообщении адреса приложения-отправителя и упомянутой структуры данных. Адрес приложения-отправителя в сообщении задается адаптером, соответствующим этому приложению-отправителю, при формировании данного сообщения. Поскольку одним из основных аспектов настоящего изобретения является то, что именно приложения являются инициаторами взаимодействия и определяют его регламент, при коммутации принятого от приложения-отправителя сообщения упомянутое множество коммутационных устройств выполняет его буферизацию и выдает буферизованное сообщение по меньшей мере одному приложению-получателю после приема запроса на выдачу сообщения от упомянутого по меньшей мере одного приложенияполучателя. Предпочтительно, конфигурационные данные сети информационной коммутации дополнительно содержат для каждой записи упомянутой структуры данных информацию о маршруте, представляющем собой совокупность коммутационных устройств, содержащую по меньшей мере одно коммутационное устройство и подлежащую использованию для коммутации сообщений от приложения-отправителя до приложения получателя, заданных в упомянутой записи. При этом конфигурационные данные сети информационной коммутации хранятся на упомянутом множестве коммутационных устройств распределенным образом, так что конфигурационные данные сети информационной коммутации разделены на части на основе упомянутой информации о маршрутах и каждое из упомянутого множества коммутационных устройств хранит соответствующую ему часть конфигурационных данных сети информационной коммутации. В предпочтительном варианте осуществления множество коммутационных устройств из состава сети информационной коммутации представляет собой множество соответствующих настоящему изобретению информационных коммутаторов, каждый из которых представляет собой устройство, предназна-4 006307 ченное для коммутации сообщений, пересылаемых между распределенными приложениями. Информационный коммутатор включает в себя сетевые средства для осуществления обмена данными в сети, запоминающее устройство для хранения конфигурационных данных информационного коммутатора и буферизации сообщений, при этом конфигурационные данные информационного коммутатора включают в себя структуру данных, каждая запись которой содержит адрес приложения-отправителя и адрес локального получателя, причем в каждой записи адрес приложения-отправителя позволяет однозначно определить адрес локального получателя. Также информационный коммутатор включает в себя логические средства, выполненные с возможностью организации одного или более буферов для сообщений в запоминающем устройстве; определения адреса приложения-отправителя из принятого от локального отправителя сообщения; обработки принятого сообщения с целью определения по меньшей мере одного адреса локального получателя на основе адреса приложения-отправителя и упомянутой структуры данных и помещения сообщения по меньшей мере в один из упомянутых буферов; обработки запроса на получение буферизованного сообщения, принятого по меньшей мере от одного локального получателя, и отправки буферизованного сообщения по меньшей мере одному локальному получателю. Следует отметить, что конфигурационные данные информационного коммутатора, по меньшей мере в своей части,относящейся к коммутации сообщений, представляют собой вышеупомянутую часть конфигурационных данных сети информационной коммутации. Локальным отправителем может являться либо приложение-отправитель, либо другой информационный коммутатор, а локальным получателем может являться либо приложение-получатель, либо другой информационный коммутатор. В предпочтительном варианте осуществления запросы на получение буферизованных сообщений выдают только приложения-получатели. Предпочтительно, логические средства из состава информационного коммутатора организуют буфер для каждого локального получателя, адрес которого содержит структурe данных из состава конфигурационных данных информационного коммутатора. Если при этом по меньшей мере одним локальным получателем является приложение-получатель, то для каждого приложения-получателя буфер, в который логические средства помещают принятое сообщение, является локальным буфером, соответствующим приложению-получателю, и отправка сообщения приложению-получателю из локального буфера осуществляется после приема запроса от приложения-получателя. Если же по меньшей мере одним локальным получателем является другой информационный коммутатор, при этом для каждого другого информационного коммутатора буфер, в который логические средства помещают принятое сообщение, является транзитным буфером, соответствующим другому информационному коммутатору, а отправка сообщения другому информационному коммутатору из транзитного буфера осуществляется по инициативе информационного коммутатора, в транзитном буфере которого находится данное сообщение. Таким образом, в предпочтительном варианте осуществления сети информационной коммутации в каждом из упомянутых маршрутов для первого информационного коммутатора в этом маршруте локальным отправителем является приложение-отправитель, для последнего информационного коммутатора в этом маршруте локальным получателем является приложение-получатель, а при наличии в этом маршруте по меньшей мере одного промежуточного информационного коммутатора локальным отправителем и локальным получателем для упомянутого по меньшей мере одного промежуточного информационного коммутатора будут соответствующие другие информационные коммутаторы этого маршрута. Согласно способу организации взаимодействия между множеством распределенных приложений,реализуемому соответствующей настоящему изобретению системой интеграции приложений, адаптер,соответствующий приложению-отправителю, выполняет обработку полученных от приложенияотправителя данных, подлежащих пересылке другому приложению, формирует сообщение, содержащее эти данные, добавляя при этом к сообщению адрес приложения-отправителя, и пересылает сформированное сообщение в сеть информационной коммутации. Сеть информационной коммутации на основе своих конфигурационных данных выполняет коммутацию пересланного сообщения по меньшей мере одному маршруту, каждый из которых соответствует записи в структуре данных из состава упомянутых конфигурационных данных, которая содержит адрес упомянутого приложения-отправителя, и выполняет промежуточную буферизацию упомянутого сообщения при его коммутации. В предпочтительном варианте осуществления сеть информационной коммутации принимает пересланное сообщение посредством информационного коммутатора, для которого упомянутое приложениеотправитель является локальным отправителем, причем в каждом из упомянутого по меньшей мере одного маршрута упомянутый информационный коммутатор является первым. При этом при коммутации упомянутого сообщения по каждому из упомянутого по меньшей мере одного маршрута каждый из образующих этот маршрут одного или более информационных коммутаторов определяет адрес приложения-отправителя из упомянутого сообщения, на основе своих конфигурационных данных и адреса приложения-отправителя определяет одного или более локальных получателей, буферизует упомянутое сообщение и, если этот информационный коммутатор не является последним в этом маршруте, пересылает упомянутое сообщение далее по маршруту.-5 006307 Затем каждый из адаптеров, соответствующих одному или более приложениям-получателям, формирует запрос на получение упомянутого сообщения и посылает его в сеть информационной коммутации. Сеть информационной коммутации принимает и обрабатывает упомянутый запрос и посылает буферизованное сообщение каждому из адаптеров, соответствующих упомянутым одному или более приложениям-получателям. В предпочтительном варианте осуществления, сеть информационной коммутации принимает запросы от адаптера приложения-получателя посредством информационного коммутатора, для которого это приложение-получатель является локальным получателем, причем этот информационный коммутатор является последним в маршруте, соответствующем этому приложению-получателю. Наконец, каждый из адаптеров, соответствующих упомянутым одному или более приложениямполучателям, обрабатывает принятое от сети информационной коммутации сообщение и предоставляет данные из него соответствующему ему приложению-получателю. Как следует из вышеизложенного, в предложенной системе интеграции распределенных приложений все возможные взаимодействия между этими приложениями определяются конфигурационными данными сети информационной коммутации. Согласно настоящему изобретению, управление взаимодействием реализуется посредством надлежащей модификации упомянутых конфигурационных данных,что является преимуществом, поскольку эта модификация ни в коей мере не затрагивает сами приложения. В соответствии с вышесказанным, в предпочтительном варианте осуществления сеть информационной коммутации дополнительно содержит систему управления, выполненную с возможностью модификации конфигурационных данных сети информационной коммутации с целью управления взаимодействием приложений. При этом система управления при внесении изменений в конфигурационные данные сети коммутации сообщений модифицирует конфигурационные данные информационных коммутаторов, задействуемых вносимыми изменениями. В предпочтительном варианте осуществления система управления выполнена с возможностью хранения полной копии конфигурационных данных сети информационной коммутации и репликации изменений, вносимых в эту копию конфигурационных данных сети информационной коммутации, в конфигурационные данные информационных коммутаторов, задействуемых этими изменениями. Таким образом, соответствующая настоящему изобретению система интеграции множества распределенных приложений осуществляет управление взаимодействием между этими приложениями с помощью системы управления из состава сети информационной коммутации, которая изменяет взаимодействие между двумя или более приложениями из упомянутого множества распределенных приложений посредством модификации структуры данных из состава конфигурационных данных сети информационной коммутации, изменяя в упомянутой структуре данных одну или более записей, определяющих упомянутое взаимодействие и содержащих адреса упомянутых двух или более приложений. Если изменение взаимодействия представляет собой добавление нового взаимодействия, то при модификации структуры данных из состава конфигурационных данных сети информационной коммутации система управления добавляет в упомянутую структуру данных одну или более новых записей, определяющих упомянутое новое взаимодействие и содержащих адреса упомянутых двух или более приложений. При этом в предпочтительном варианте осуществления в структуру данных из состава хранящейся в системе управления полной копии конфигурационных данных сети информационной коммутации добавляется одна или более новых записей, определяющих упомянутое новое взаимодействие и содержащих адреса упомянутых двух или более приложений. Затем для каждой из упомянутых новых записей в упомянутой полной копии конфигурационных данных задается маршрут в сети информационной коммутации. После этого выполняется модификация конфигурационных данных каждого информационного коммутатора из информационных коммутаторов, образующих каждый из упомянутых маршрутов, посредством выполнения репликации соответствующей этому маршруту записи в структуру данных из состава конфигурационных данных этого информационного коммутатора. Если же изменение взаимодействия представляет собой удаление существующего взаимодействия,то при модификации структуры данных из состава конфигурационных данных сети информационной коммутации система управления удаляет из упомянутой структуры данных записи, содержащие адреса упомянутых двух или более приложений и определяющие упомянутое взаимодействие. При этом в предпочтительном варианте осуществления в структуре данных из состава хранящейся в системе управления полной копии конфигурационных данных сети информационной коммутации выполняется определение одной или более записей, определяющих подлежащее удалению взаимодействие и содержащих адреса упомянутых двух или более приложений. Далее для каждой из упомянутых одной или более записей в упомянутой полной копии конфигурационных данных определяют соответствующий этой записи маршрут в сети информационной коммутации, после чего модифицируют конфигурационные данные каждого информационного коммутатора из информационных коммутаторов, образующих каждый из упомянутых маршрутов, посредством удаления соответствующей этому маршруту записи из структуры данных из состава конфигурационных данных этого информационного коммутатора. Наконец, удаляют упомянутые одну или более записей и ассоциированную с ними информацию о маршрутах из состава упомянутой полной копии конфигурационных данных.-6 006307 Дополнительным аспектом настоящего изобретения является обеспечение отказоустойчивости при коммутации сообщений в сети информационной коммутации. В соответствии с этим аспектом, в предпочтительном варианте осуществления сети информационной коммутации упомянутое множество коммутационных устройств представляет собой множество отказоустойчивых узлов коммутации, каждый из которых, по существу, представляет собой специализированную конфигурацию двух связанных между собой информационных коммутаторов, один из которых является основным информационным коммутатором, а другой - резервным информационным коммутатором. Для формирования отказоустойчивого узла коммутации каждый из составляющих его информационных коммутаторов должен быть оснащен дополнительными средствами, а именно хранилищем данных, предназначенным для хранения и управления данными информационного коммутатора, которые используются при работе информационного коммутатора и сохраняются в нем при его перезагрузке или выключении, и подсистемой восстановления после отказа, предназначенной для обеспечения отказоустойчивости. Подсистема восстановления после отказа основного информационного коммутатора содержит модуль мониторинга, выполненный с возможностью периодической посылки контрольного сигнала через заранее заданный интервал времени, и модуль синхронизации, предназначенный для обеспечения синхронизации хранилища данных и выполненный с возможностью формирования и посылки команд репликации. Подсистема восстановления после отказа резервного информационного коммутатора выполнена с возможностью поддержания неактивного состояния этого информационного коммутатора, в котором он не осуществляет коммутацию сообщений, а только обрабатывает принимаемую сигнальную служебную информацию, при этом подсистема восстановления после отказа содержит модуль синхронизации, предназначенный для обеспечения синхронизации хранилища данных, и модуль переключения на резерв, предназначенный для вывода резервного информационного коммутатора из неактивного состояния. Таким образом предложенный отказоустойчивый узел коммутации содержит связанные между собой основной информационный коммутатор, находящийся в активном состоянии, в котором выполняется коммутация, и резервный информационный коммутатор, находящийся в неактивном состоянии. Основной и резервный информационные коммутаторы в любой момент времени обеспечивают синхронизацию своих хранилищ данных посредством своих модулей синхронизации. При этом подсистема восстановления после отказа резервного информационного коммутатора переводит его в активное состояние при отказе основного информационного коммутатора без прерывания работы отказоустойчивого узла коммутации. Следует отметить, что основной и резервный информационные коммутаторы имеют идентичные адреса и конфигурационные данные, идентичные в части, обеспечивающей коммутацию сообщений, представляя таким образом единый узел коммутации соответствующей настоящему изобретению сети информационной коммутации. Перечень фигур чертежей Ниже приводится подробное описание изобретения со ссылками на сопроводительные чертежи, на которых фиг. 1 - пример подключения к одному серверу трех клиентов; фиг. 2 - иллюстрация увеличения количества информационных связей при наращивании системы по фиг. 1; фиг. 3 - иллюстрация использования процессов-маршрутизаторов для организации "виртуальной" сети; фиг. 4 - иллюстрация сетевого устройства в качестве основы системы интеграции приложений; фиг. 5 - уровни абстракции модели передачи данных; фиг. 6 - общая схема взаимодействия приложений через сеть информационной коммутации согласно настоящему изобретению; фиг. 7 - блок-схема последовательности операций способа организации взаимодействия между приложениями, реализуемого системой интеграции приложений, соответствующей настоящему изобретению; фиг. 8 - иллюстрация конкретного примера интеграции приложений согласно настоящему изобретению; фиг. 9 - технологический цикл функционирования отказоустойчивого узла коммутации, соответствующего настоящему изобретению; фиг. 10 - иллюстрация синхронизации приема и обработки данных; фиг. 11 - иллюстрация согласования форматов данных для обмена между приложениями; фиг. 12 - иллюстрация добавления подсистемы; фиг. 13 - иллюстрация интеграции систем в надсистему; фиг. 14 - иллюстрация разделения трафика входящих и исходящих сообщений; фиг. 15 - иллюстрация функционального разделения информационного трафика; фиг. 16 - иллюстрация демпфирующих свойств информационных коммутаторов при обращении к нагруженному серверному устройству;-7 006307 фиг. 17 - иллюстрация контроля регламента обработки данных. Подробное описание изобретения В соответствии с вышесказанным, основной задачей настоящего изобретения является обеспечение интеграции распределенных приложений посредством организации взаимодействия между этими приложениями таким образом, чтобы сами приложения были по максимуму изолированы от непосредственной реализации и деталей этого взаимодействия, являясь при этом его инициаторами, и для решения этой задачи предложена соответствующая настоящему изобретению система интеграции приложений, обеспечивающая взаимодействие распределенных приложений. Интеграция распределенных приложений, которые могут быть разнесены географически на значительные расстояния, и ассоциированное с ней взаимодействие подразумевают организованный надлежащим образом сетевой обмен данными между приложениями, который в общем случае может быть довольно сложным и интенсивным, поскольку каждое приложение может взаимодействовать с несколькими разнородными приложениями, причем характер этих взаимодействий может существенно отличаться. Разнородность программных приложений может, и чаще всего имеет место, даже в пределах одного предприятия. Такая разнородность может включать в себя различия: источников возникновения и сопровождения программного обеспечения; видов операционных и вспомогательных систем, с которыми обеспечена совместимость приложений; форматов хранения, обработки и передачи данных, связанных с приложениями; сферой применения или областью знаний, на которые ориентированы приложения; и т.п. В таком случае само понятие "приложение" заставляет воспринимать всю совокупность прикладных программных средств, в виде набора разрозненных элементов, отнесенных (приложенных) к разным частям одного или того же предприятия или даже одного и того же производственного процесса. При этом,оказываются затруднены все функции комплексного контроля и анализа производственных процессов и процессов управления предприятия, а следовательно, и согласованного управления этими процессами. Для решения указанной проблемы может быть применена интеграция уже существующих программных приложений, которая подразумевает объединение приложений в единую информационную систему, использующую результаты работы приложений для единой цели. Очевидно, что такая интеграция невозможна без организации обмена данными между упомянутыми приложениями, поскольку предметом и результатом работы приложений всегда являются данные того или иного формата, поступающие с той или иной интенсивностью, по тому или иному направлению ввода или вывода. Следовательно, для упомянутой интеграции приложений необходимо предложить способ и/или систему, обеспечивающие передачу данных различных форматов, порядка и адреса следования между упомянутыми приложениями. При этом должны быть обеспечены: надежная доставка данных от одного или более приложенийотправителей одному или более приложениям-получателям, совместимость форматов данных обменивающихся приложений и выполнение присущего таким приложения временного регламента обмена данными. Вышеупомянутая система интеграции приложений, соответствующая настоящему изобретению,включает в себя сеть информационной коммутации и совокупность логических средств-адаптеров, обеспечивающих взаимодействие распределенных приложений с сетью информационной коммутации. В совокупности упомянутые сеть информационной коммутации и логические средства-адаптеры, которые раскрыты более подробно ниже, обеспечивают обмен данными между приложениями, определяющий их взаимодействие. В основу построения соответствующей настоящему изобретению системы интеграции приложений положена описываемая ниже модель передачи данных (МПД). Модель передачи данных Модель передачи данных (МПД) описывает способ организации и управления взаимодействием приложений по принципу информационной коммутации, при этом взаимодействующие приложения обмениваются данными в виде пересылаемых сообщений. Сеть информационной коммутации, которая в материалах заявки также называется сетью коммутации сообщений, предоставляет приложениям универсальную транспортную среду для организации асинхронного взаимодействия и предоставляет средства управления структурой информационного обмена. Под структурой информационного обмена понимается упорядоченное множество информационных связей, при этом информационная связь - это абстрактный объект (по существу, набор правил), определяющий взаимодействие путем регламентации обмена данными между несколькими приложениями. Информационная связь определяется 1. приложением-отправителем и непустым множеством приложений-получателей данных; 2. форматом данных; 3. временными ограничениями на процесс доставки данных до всех отправителей. В соответствии с вышесказанным, каждое приложение по отношению к сети информационной коммутации представлено своим адаптером, который в материалах заявки также называется ИК-стеком. ИК-стек представляет собой подсистему приложения, которая, предпочтительно, создается разработчиками для вновь разрабатываемого приложения в качестве его неотъемлемой части, а для существующих-8 006307 приложений создается в виде отдельного дополнительного модуля, например, в виде программной подключаемой библиотеки. Тем не менее, при желании, ИК-стек может быть реализован и в виде элемента аппаратных средств, например, в виде аппаратного логического автомата, выполненного на БИС. МПД является уровневой и включает в себя уровни абстракции, приведенные в табл. 1. Таблица 1. Уровни абстракции МПД Каждый уровень абстракций модели передачи данных определяет множество объектов и механизмы взаимодействия между ними, а также интерфейсы, предоставляемые каждым уровнем абстракции и обеспечивающие в целом реализацию специальной транспортной подсистемы. Взаимоотношения указанных уровней абстракции приведены на фиг. 5. Взаимодействие между уровнями абстракции осуществляется путем вызова на вышележащем уровне функций нижележащего уровня. По отношению к модели передачи данных ИК-стек: 1. предоставляет другим подсистемам приложения интерфейс уровня ADD для взаимодействия с сетью информационной коммутации; 2. реализует функциональность уровня РМТ с использованием интерфейса транспортного уровня; 3. обеспечивает инкапсуляцию и деинкапсуляцию передаваемых между уровнями данных. При передаче или приеме данных управление в приложении передается от уровня ADD через уровень РМТ до транспортного уровня. Поскольку приложение по отношению к сети информационной коммутации представлено своим ИК-стеком на каждом из уровней абстракции ADD и РМТ, то при рассмотрении каждого из уровней допускается использовать термины "приложение" и "ИК-стек" как синонимы в пределах рассматриваемого уровня абстракции МПД. Уровень ADD Уровень ADD определяет механизм взаимодействия приложения и сети информационной коммутации как единой специальной транспортной среды, а также параметры указанной сети, изменение которых обеспечивает управление структурой информационного обмена. При передаче и приеме данных приложение на уровне ADD взаимодействует посредством ИК-стека только с сетью информационной коммутации. Взаимодействие приложения с сетью информационной коммутации является асинхронным в том смысле, что приложение непосредственно управляет регламентом и режимом передачи данных и регламентом получения данных, что описывается ниже. Единицей передачи и приема данных для приложения в рамках конкретной информационной связи на уровне ADD является сообщение протокола информационного обмена (ПИО), обозначаемое как ПИОС. Все ПИОС в рамках конкретной информационной связи имеют единый формат данных. По существу, взаимодействие приложения и сети информационной коммутации сводится к передаче ПИОС и получению ПИОС. При передаче или получении ПИОС приложение управляет выбором информационной связи с помощью идентификатора информационной связи, уникального на множестве информационных связей этого приложения, который называется ПИО-портом. По отношению к приложению может быть выделено множество входящих информационных связей, через которые происходит получение ПИОС, а также множество исходящих информационных связей, через которые происходит передача ПИОС. Указанным множествам в приложении могут быть сопоставлены множества входящих и исходящих ПИО-портов. При передаче ПИОС приложение-отправитель определяет ПИО-порт соответствующей информационной связи, через которую осуществляется передача указанного ПИОС, а также режим передачи, и передает ПИОС в сеть информационной коммутации. Для получения ПИОС приложение-получатель осуществляет запрос у сети информационной коммутации определенного входящего ПИО-порта. При наличии в сети информационной коммутации ПИОС данной информационной связи с данным ПИО-портом, приложение-получатель принимает от сети-9 006307 информационной коммутации соответствующее ПИОС, при этом по одному запросу приложениюполучателю может быть передано только одно ПИОС. МПД определяет два режима передачи ПИОС приложением-отправителем - блокируемый и неблокируемый режимы передачи. При использовании приложением-отправителем неблокируемого режима передача для приложенияотправителя завершается сразу после успешного получения ПИОС сетью информационной коммутации. Сеть информационной коммутации в дальнейшем пытается доставить ПИОС всем получателям в рамках информационной связи, однако результат доставки не сообщается приложению-отправителю и никак не влияет на его дальнейшую работу. При использовании приложением блокируемого режима передача для приложения-отправителя завершается успешно только после получения ПИОС всеми приложениями-получателями в рамках заданной информационной связи в течение времени жизни ПИОС в сети информационной коммутации. Между приложением и сетью информационной коммутации существует разделение ответственности. Сеть информационной коммутации контролирует параметры информационной связи-отправителя и получателей ПИОС, а также время нахождения ПИОС в сети информационной коммутации в рамках информационной связи. Приложения же, в соответствии с вышесказанным, контролируют регламент и режим передачи ПИОС, регламент получения ПИОС. Таким образом, согласно вышесказанному на уровне ADD взаимодействия между распределенными приложениями задаются совокупностью информационных связей между приложениями. Все информационные связи в сети информационной коммутации заданы в глобальной таблице коммутации (ГТК),записи которой содержат 1. описание коммутационной пары, а также, в необязательном порядке,2. описание типа информационной связи; 3. значение времени актуальности ПИОС. При этом для специалиста в данной области техники должно быть очевидно, что глобальная таблица коммутации не является единственно возможной структурой данных для хранения информации об информационных связях, и можно использовать любую другую подходящую структуру данных, обеспечивающую функциональные возможности глобальной таблицы коммутации. Рассмотрим более подробно содержимое записей глобальной таблицы коммутации. Каждая информационная связь LN, описывающая взаимодействие некоторого подмножества приложений, может быть однозначно задана непустым множеством коммутационных пар IDiPj -IDkPl, гдеPj - ПИО-порт, уникально идентифицирующий информационную связь по отношению к приложению-отправителю IDi (ПИО-порт приложения-отправителя);Pl - ПИО-порт, уникально идентифицирующий информационную связь по отношению к приложению-получателю IDk (ПИО-порт приложения-получателя). Глобальная таблица коммутации по существу содержит множество коммутационных пар IDiPj IDkPl, где IDiPj определяет уникальный адрес (адресную пару) приложения-отправителя, a IDkPl уникальный адрес (адресную пару) приложения-получателя. Множество записей ГТК с общей адресной парой отправителя IDiPj - IDkPl определяет передачу конкретного ПИОС от одного приложенияотправителя к одному или более приложениям-получателям в рамках одной информационной связи. Множество всех записей ГТК определяет все допустимые варианты передачи ПИОС в сети информационной коммутации. Для каждой информационной связи в сети информационной коммутации задан параметр Type (LN),значение которого соответствует одному из нижеперечисленных типов информационной связи: обычный тип информационной связи; вытесняющий тип информационной связи. Для связей обычного типа все ПИОС, переданные приложением-отправителем, будут храниться в сети информационной коммутации до тех пор, пока либо не будут запрошены и получены приложениемполучателем, либо не истечет время актуальности указанного ПИОС. Для связей вытесняющего типа каждое новое ПИОС, переданное приложением-отправителем в рамках информационной связи, заменяет (или вытесняет) предыдущее ПИОС, переданное сети информационной коммутации в рамках рассматриваемой информационной связи. Таким образом, пока не истечет время актуальности, все приложения-получатели в рамках связи вытесняющего типа всегда имеют доступ только к одному ПИОС, которое может быть интерпретировано как последнее актуальное. Поскольку каждая информационная связь LN в сети информационной коммутации может быть представлена в виде множества коммутационных пар ГТК(LN), для каждой адресной пары приложенияотправителя IDiPj из совокупности записей ГТК, соответствующих LN, задан параметр Type(IDiPj), который соответствует Type(LN). Параметр Type(IDiPj) определен в ГТК для каждой коммутационной пары.- 10006307 Для каждой информационной связи LN в сети информационной коммутации может быть определен параметр Time(LN), задающий время актуальности ПИОС в сети информационной коммутации, которое ограничивает время нахождения ПИОС в данной сети. Время нахождения ПИОС в сети информационной коммутации отсчитывается с момента окончания приема ПИОС сетью информационной коммутации от приложения-отправителя и заканчивается моментом начала передачи ПИОС сетью информационной коммутации приложению-получателю. Время нахождения ПИОС в сети информационной коммутации не должно превышать значения параметра времени актуальности Time(LN). Поскольку каждая информационная связь LN в сети информационной коммутации может быть представлена в виде множества коммутационных пар ГTK(LN), для каждой адресной пары приложенияотправителя IDiPj из совокупности записей ГТК, соответствующих LN, задан параметр Time(IDiPj), который соответствует Time(LN). Параметр Time(IDiPi) определен в ГТК для каждой коммутационной пары. Уровень РМТ Уровень РМТ определяет механизм передачи ПИОС уровня ADD, инкапсулированного в единицу передачи данных уровня РМТ, от приложения-отправителя к приложениям-получателям через сеть информационной коммутации. Единицей передачи данных на уровне РМТ является РМТ-пакет. Все взаимодействия на уровне РМТ определены исключительно между адресуемыми объектами уровня РМТ, которыми являются ИКстеки и узлы сети информационной коммутации, представляющие собой сетевые устройства коммутации, также называемые в настоящем описании узлами коммутации. Более подробное описание узлов сети информационной коммутации приводится ниже. ИК-стек на уровне РМТ является подсистемой приложения, функционирующей на уровне РМТ, которая предоставляет для уровня ADD функциональные вызовы для передачи и получения ПИОС уровняADD через уровень РМТ, обеспечивает инкапсуляцию ПИОС уровня ADD в РМТ-пакет и обратную деинкапсуляцию, и взаимодействует с узлом коммутации. Узел коммутации взаимодействует с ИК-стеками и другими узлами коммутации для осуществления коммутации ПИОС на уровне РМТ, которая представляет собой процесс передачи ПИОС уровня РМТ от ИК-стека приложения-отправителя к ИК-стекам одного или более приложений-получателей через множество взаимодействующих между собой узлов коммутации. Коммутация называется одноадресной, если для коммутируемого ПИОС определено только одно приложение-получатель, и многоадресной, если для коммутируемого ПИОС определено более одного приложения-получателя. Процесс коммутации ПИОС подробно описан ниже. Топология сети информационной коммутации определена таким образом, что для каждого ИКстека определен один и только один узел коммутации, с которым ИК-стек взаимодействует для передачи и приема ПИОС. Указанный узел коммутации называется локальным для такого ИК-стека, в свою очередь такой ИК-стек называется локальным для этого узла коммутации ИК. По существу, топология сети информационной коммутации описывает объединение множества узлов коммутации и ИК-стеков в сеть и представляет собой направленный граф, вершинами которого являются узлы коммутации и ИК-стеки, а наличие между ними ребра и его направление задает возможность и направление передачи ПИОС. Между двумя любыми вершинами на этом графе может существовать два разнонаправленных ребра, но не может существовать более одного ребра одного направления. На графе сети для каждого ИК-стека может быть определен только один узел коммутации, с которым у ИК-стека есть общие ребра. Указанный узел коммутации является локальным для рассматриваемого ИК-стека. Между локальным узлом коммутации и ИК-стеком может быть определено два и только два разнонаправленных ребра. При наличии определенного локального узла коммутации ИК-стек считается подключенным. Далее приводится описание адресации уровня РМТ и глобальные параметры коммутации. Как отмечено ранее, на уровне РМТ объекты (узлы коммутации и ИК-стеки) являются адресуемыми, т.е. для каждого объекта уровня РМТ определен уникальный идентификатор - РМТ-адрес, обозначаемый далее как S. В соответствии с вышесказанным, для идентификации конкретной информационной связи используется уникальный для рассматриваемого приложения идентификатор информационной связи - ПИОпорт, обозначаемый далее Р. Поскольку каждый ИК-стек однозначно сопоставляется с приложением, участвующем в передаче и приеме ПИОС, то для каждого вышеупомянутого идентификатора приложения ID уровня ADD может быть однозначно сопоставлен РМТ-адрес S. Глобальной таблице коммутации уровня ADD ставится в соответствие глобальная таблица коммутации уровня РМТ, в которой для каждой коммутационной пары IDiPj - IDkPl ГТК уровня ADD поставлена в соответствие коммутационная пара SiPj - SkPl ГТК уровня РМТ, где Si и Sk являются РМТ-адресами соответствующих приложений IDi и IDk. По аналогии с описанием уровня ADD, для каждой адресной пары приложения-отправителя SiPj в ГТК уровня РМТ может быть определен параметр Time(SiPj), равный соответствующему параметруTime(IDiPj) уровня ADD и ограничивающий время нахождения ПИОС в сети информационной коммута- 11006307 ции, а также параметр Type (SiPj), соответствующий параметру Type(IDiPj) уровня ADD и определяющий тип информационной связи. При этом для связей обычного типа все ПИОС, переданные ИК-стеком приложения-отправителя локальному узлу коммутации, будут храниться в сети информационной коммутации до тех пор, пока либо не будут запрошены и получены приложением-получателем, либо не истечет время актуальности указанного ПИОС; для связей вытесняющего типа каждое новое ПИОС, переданное ИК-стеком приложенияотправителя в рамках информационной связи локальному узлу коммутации, заменяет (или вытесняет) в сети информационной коммутации предыдущее ПИОС, переданное в рамках этой информационной связи, причем для рассматриваемого ПИОС действуют все ограничения, связанные с временем актуальности. Как было сказано ранее, единицей передачи данных на уровне РМТ является РМТ-пакет, состоящий из заголовка и тела. Заголовок РМТ-пакета в соответствующих полях содержит параметры, определяющие характеристики пакета, влияющие, в общем случае, на его обработку и коммутацию в сети. В состав заголовка могут входить, например, следующие параметры: РМТ-адрес приложения, ПИО-порт,идентификатор типа РМТ-пакета, метка блокируемой передачи и временной параметр, определяющий остаток времени нахождения ПИОС в сети информационной коммутации. Определены следующие типы РМТ-пакетов: 1. ПИОС уровня РМТ - РМТ-пакет, тело которого содержит инкапсулированные данные уровняADD; 2. ПУПС (Пакет Управления Передачей Сообщения) - РМТ-пакет, несущий служебную информацию, необходимую для управления коммутацией в сети информационной коммутации. В свою очередь, определены следующие типы ПУПС: 1. ПУПС-запрос - ПУПС, содержащий запрос приложения-получателя на выдачу ПИОС; 2. ПУПС-квитанция - ПУПС, содержащий подтверждение о доставке ПИОС приложениямполучателям; 3. ПУПС-запрос квитанции - ПУПС, содержащий запрос приложения-отправителя на выдачу подтверждения о доставке ПИОС всем приложениям-получателям; 4. ПУПС-ответ - ПУПС, посылаемый узлом коммутации в ответ на ПИОС или ПУПС-квитанцию(приложению или другому узлу коммутации). Вышеприведенный список типов ПУПС не является закрытым и при необходимости можно ввести дополнительные типы ПУПС. Тело РМТ-пакета определено только для вышеупомянутого ПИОС уровня РМТ и содержит ПИОС уровня ADD, тогда как для других типов РМТ-пакетов содержимое тела не определено. Транспортный уровень Транспортный уровень предназначен для реализации надежного механизма обмена РМТ-пакетами между адресуемыми объектами уровня РМТ. Предпочтительно, транспортный уровень реализуется на базе известного стека протоколов TCP/IP,однако специалистам в данной области техники следует понимать, что в качестве протоколов транспортного уровня могут использоваться любые известные протоколы, подходящие для конкретной практической реализации настоящего изобретения. Протоколы транспортного уровня должны обеспечивать взаимодействие типа "запрос-ответ" при обмене РМТ-пакетами между объектами уровня РМТ. При этом транспортные протоколы должны обеспечивать при таком взаимодействии передачу целого РМТ-пакета без фрагментации на уровне РМТ, а также предоставлять информацию об ошибках в случае их возникновения при передаче. Наглядная схема взаимодействия распределенных приложений через сеть информационной коммутации согласно настоящему изобретению показана на фиг. 6. Далее со ссылкой на вышеизложенную модель передачи данных, лежащую в основе настоящего изобретения, приводится описание компонентов системы интеграции приложений, соответствующей настоящему изобретению. В соответствии с вышесказанным, система интеграции множества распределенных приложений содержит сеть информационной коммутации сообщений и множество ИК-стеков, предназначенных для обеспечения взаимодействия приложений с сетью информационной коммутации, при этом каждый ИКстек из упомянутого множества ИК-стеков однозначно сопоставлен приложению из упомянутого множества распределенных приложений. Далее приводится подробное описание ИК-стека и выполняемых им функций. Следует отметить,что в контексте настоящего изобретения ИК-стек носит вспомогательную функцию и, по существу,представляет собой адаптер для приложения, реализуемый известными из уровня техники способами и средствами и имеющий конкретную специализацию, а именно обеспечение совместимости приложений с сетью информационной коммутации, соответствующей одному из основных аспектов настоящего изобретения.- 12006307 В одном из предпочтительных вариантов осуществления ИК-стек реализован в виде динамической программной библиотеки, адаптированной для использования различных широко известных языков программирования, в том числе Perl, PHP, Python, VB. При этом при взаимодействии с сетью информационной коммутации приложение может создавать несколько экземпляров ИК-стека, однако в этом случае вся совокупность экземпляров ИК-стека охватывается единым понятием "ИК-стек". В соответствии с вышесказанным, при взаимодействии с сетью информационной коммутации на уровне РМТ именно ИК-стек, являющийся подсистемой приложения, представляет собой адресуемый объект, следовательно, адресация приложения при коммутации сообщений в соответствии с настоящим изобретением реализуется посредством ИК-стека. В предпочтительном варианте осуществления, соответствующему вышеизложенной модели передачи данных, ИК-стек выполнен с возможностью присвоения соответствующему ему приложению РМТадреса (S), а также присвоения упомянутому приложению по меньшей мере одного ПИО-порта (Р), каждый из которых определяет для данного приложения конкретную информационную связь. Согласно вышесказанному, совместно с РМТ-адресом каждый из упомянутых ПИО-портов обеспечивает для приложения уникальный адрес (адресную пару) для взаимодействия с другими приложениями через сеть информационной коммутации на уровне РМТ, и именно такие пары содержатся в записях глобальной таблицы коммутации сети информационной коммутации. Для взаимодействия с приложением на уровнеADD ИК-стек задает приложению идентификатор (ID) уровня ADD, который, согласно вышесказанному,однозначно соответствует РМТ-адресу этого приложения. В соответствии с вышесказанным, ИК-стек обеспечивает обмен сообщениями между соответствующим ему приложением и сетью информационной коммутации. При посылке сообщения в рамках конкретной информационной связи ИК-стек на уровне ADD получает от приложения данные и формирует сообщение (ПИОС), содержащее эти данные, которое затем ИК-стек на уровне РМТ инкапсулирует в РМТ-пакет и добавляет к нему РМТ-адрес приложения и соответствующий этой информационной связи ПИО-порт, после чего пересылает этот РМТ-пакет в сеть информационной коммутации. Предпочтительно, ИК-стек вносит упомянутые РМТ-адрес и ПИО-порт в соответствующие поля заголовка формируемого РМТ-пакета. При приеме сообщения из сети информационной коммутации ИК-стек выполняет последовательность операции, обратную вышеописанной последовательности операции при отправке сообщения, а именно деинкапсуляцию принятого РМТ-пакета на уровне РМТ и предоставление извлеченного ПИОС приложению с уровня ADD. Помимо этого, ИК-стек отвечает за формирование и передачу служебных сообщений уровня РМТ(в виде вышеописанных пакетов ПУПС) в сеть информационной коммутации, а также прием и обработку служебных сообщений из сети информационной коммутации. Этот аспект функционирования ИК-стека подробно описывается при изложении предпочтительного варианта осуществления работы системы интеграции приложений, соответствующей настоящему изобретению. Следует отметить, что при формировании пакета ПИОС или ПУПС ИК-стек заносит в соответствующие поля заголовка этого пакета метку типа этого пакета, а при приеме любого пакета из сети информационной коммутации ИК-стек анализирует заголовок принятого пакета и, заранее зная формат этого заголовка, извлекает метку типа этого пакета. Естественно, ПУПС не предоставляется приложению, поскольку представляет интерес только для самого ИК-стека, но не для других подсистем приложения. Кроме того, в соответствии с вышеупомянутой границей ответственности приложения ИК-стек выполнен с возможностью задания либо блокируемого режима передачи сообщения, либо неблокируемого режима передачи сообщения, предпочтительно, в соответствии со значением параметра, передаваемым приложением при обращении к функциям соответствующего ему ИК-стека. При задании режима передачи ИК-стек заносит метку режима передачи в соответствующее поле заголовка формируемого им РМТпакета, в который инкапсулируется сообщение. Помимо этого, ИК-стек выполнен с возможностью буферизации передаваемых и принимаемых сообщений. Буферизация реализуется известными из уровня техники средствами и способами, например, посредством вызова ИК-стеком функций операционной системы на вычислительном устройстве, на котором исполняется приложение. Как было отмечено ранее, в одном из предпочтительных вариантов осуществления ИК-стек реализован в виде динамической программной библиотеки, представляющей собой набор функций, вызываемых приложением. При вызовах упомянутых функций в качестве их аргументов, в частности, используются идентификатор (ID) приложения и надлежащий ПИО-порт. В этом предпочтительном варианте осуществления ИК-стек содержит следующие функции передачи ПИОС: передача неблокируемого сообщения из промежуточного буфера; передача блокируемого сообщения из промежуточного буфера; передача неблокируемого сообщения из файла; передача блокируемого сообщения из файла. Удачно завершенная функция возвращает нулевое значение, в случае ошибки - код ошибки.- 13006307 В этом предпочтительном варианте осуществления ИК-стек содержит следующие функции приема ПИОС: прием сообщения в буфер; определение длины последнего принятого в буфер сообщения; прием сообщения в промежуточный файл. В случае успешного получения сообщения функция возвращает его длину, а в случае ошибки - нулевое значение. Помимо этого, в этом предпочтительном варианте осуществления ИК-стек содержит следующие функции для обработки исключений (возможных ошибок, возникающих при работе с ИК-стеком): взять код ошибки последней операции; взять описание ошибки последней операции. Функция взятия кода ошибки последней операции возвращает код ошибки последней операции ИКстека в текущем потоке. Основным компонентом соответствующей настоящему изобретению системы интеграции распределенных приложений является сеть информационной коммутации. Сеть информационной коммутации предназначена для организации взаимодействия распределенных приложений посредством коммутации пересылаемых между ними сообщений. Как было упомянуто ранее, сеть информационной коммутации содержит множество узлов коммутации, которое выполняет коммутацию принимаемых от приложений сообщений. Сеть информационной коммутации как единое целое характеризуется конфигурационными данными сети информационной коммутации, которые определяют все возможные взаимодействия (информационные связи) между приложениями и на основе которых осуществляется коммутация сообщений. В частности, упомянутые конфигурационные данные содержат вышеописанную глобальную таблицу коммутации уровня РМТ, каждая запись которой содержит уникальный адрес (адресную пару) приложенияотправителя и уникальный адрес (адресную пару) приложения-получателя. В соответствии с вышеописанной МПД, каждая адресная пара содержит РМТ-адрес приложения и ПИО-порт. Специалистам в данной области техники следует понимать, что используемая в настоящем изобретении адресация, соответствующая вышеизложенной модели передачи данных, а именно на основе РМТадресов и ПИО-портов, не является единственно возможной и можно использовать другие идентификаторы для обеспечения уникальной адресации распределенных приложений при коммутации сообщений между ними. Также организация данных о возможных информационных связях в виде ГТК является предпочтительной, но не обязательной, и можно использовать любую другую структуру данных, обеспечивающую требуемую функциональность. Структура ГТК такова, что зная адрес приложения-отправителя, сеть информационной коммутации может на основе записей ГТК определить одно или более приложений-получателей (в ГТК одному адресу приложения отправителя может соответствовать несколько записей с отличающимися адресами приложений-получателей при вышеописанной многоадресной коммутации), поскольку в каждой записи адрес приложения-отправителя позволяет однозначно определить адрес приложения-получателя. При этом следует иметь в виду, что, согласно вышесказанному, адрес приложения-отправителя в виде адресной пары задается соответствующим ему ИК-стеком в сообщении, посылаемом в сеть информационной коммутации. Таким образом, множество узлов коммутации из состава сети информационной коммутации выполняет коммутацию принятого от приложения-отправителя сообщения посредством определения в глобальной таблице коммутации по меньшей мере одного адреса приложения-получателя на основе заданного в сообщении адреса приложения-отправителя. Извлечение адресной пары из заголовка сообщения может быть реализовано любым подходящим известным из уровня техники способом, после чего в ГТК выявляются записи, адрес приложения-отправителя которых совпадает с извлеченным адресом. Более подробно этот процесс описан ниже при изложении узла коммутации, соответствующего настоящему изобретению. Отсюда следует, что приложение при конкретном взаимодействии не знает и не должно знать своего адресата, поскольку все детали реализации этого взаимодействия, в частности определение получателя и доставку ему данных, берет на себя сеть информационной коммутации. Это обеспечивает возможность гибкого управления взаимодействием приложений посредством надлежащей модификации конфигурационных данных сети информационной коммутации без трудоемкого перепрограммирования приложений. Такая модификация может быть реализована посредством средств конфигурирования, являющихся частью сети информационной коммутации, при этом предпочтительный вариант осуществления средств конфигурирования в виде единой системы управления описан ниже. Помимо этого, конфигурационные данные сети информационной коммутации могут надлежащим образом содержать другие параметры, определяющие взаимодействия между приложениями, например,вышеописанные время актуальности сообщения или тип информационной связи. Конфигурационные данные сети информационной коммутации хранятся в узлах коммутации данной сети, которые для этого выполнены с возможностью хранения данных (например, каждое из них ос- 14006307 нащено каким-либо известным запоминающим устройством). При коммутации сообщений узлы коммутации обращаются к локально хранящимся конфигурационным данным сети, при этом сам характер хранения конфигурационных данных не является определяющим. Например, каждый из узлов коммутации может хранить полную копию конфигурационных данных сети информационной коммутации, однако наиболее предпочтительный вариант организации хранения упомянутых конфигурационных данных сети информационной коммутации раскрыт ниже. Согласно концепции настоящего изобретения, приложение-получатель само задает регламент получения сообщения, и сеть информационной коммутации выдает сообщение приложению-получателю только после приема от него запроса на выдачу этого сообщения. До получения этого запроса сообщение должно быть буферизовано в сети, поэтому узлы коммутации из состава сети информационной коммутации выполнены с возможностью буферизации сообщений. Для буферизации может использоваться вышеупомянутое запоминающее устройство. В предпочтительном варианте осуществления конфигурационные данные сети информационной коммутации дополнительно содержат для каждой записи ГТК информацию о маршруте, представляющем собой совокупность узлов коммутации из состава сети информационной коммутации. Эта совокупность содержит по меньшей мере один узел коммутации и подлежит использованию для коммутации сообщений от приложения-отправителя до приложения получателя, заданных в упомянутой записи. Маршрут может состоять из одного узла коммутации, если и приложение-отправитель, и приложениеполучатель являются локальными по отношению к этому узлу коммутации, в противном случае маршрут будет содержать более одного узла коммутации. Маршруты задаются на основании топологии сети информационной коммутации. При этом следует отметить, что в одном из вариантов осуществления для адресации в сети информационной коммутации можно использовать не адресные пары, а идентификаторы маршрутов. Добавление информации о маршрутах позволяет эффективно реализовать распределенное хранение конфигурационных данных сети информационной коммутации на узлах коммутации. Для этого конфигурационные данные делят на части на основе информации о маршрутах и сохраняют на каждом из узлов коммутации только соответствующую ему часть конфигурационных данных. Это позволяет обеспечить компактное хранение конфигурационных данных и ускоряет обработку сообщений на каждом из узлов коммутации. Более конкретный вариант разделения конфигурационных данных сети информационной коммутации описан ниже при изложении соответствующего настоящему изобретению узла коммутации из состава сети информационной коммутации. Ниже описывается соответствующий настоящему изобретению узел коммутации из состава вышеизложенной сети информационной коммутации. Именно совокупность этих узлов коммутации реализует соответствующую настоящему изобретению концепцию сети информационной коммутации. При этом специалисты в данной области техники должны понимать, что конкретная реализация узла коммутации может отличаться от описываемой ниже. В соответствии с вышесказанным, соответствующий настоящему изобретению узел коммутации,называемый также в материалах настоящей заявки информационным коммутатором, представляет собой устройство, предназначенное для коммутации сообщений, пересылаемых между приложениями в сети. Соответствующий настоящему изобретению информационный коммутатор, а значит и сеть информационной коммутации, содержащая такие информационные коммутаторы, функционируют на уровне РМТ вышеизложенной модели передачи данных, следовательно, коммутируемые информационным коммутатором сообщения представляют собой вышеописанные ПИОС уровня РМТ. В общем случае, информационный коммутатор включает в себя сетевые средства, запоминающее устройство и совокупность логических средств, а также другие известные средства и устройства, необходимые для обеспечения функционирования информационного коммутатора (например, устройства обработки данных и сигналов, проводные соединения, интерфейсные платы, порты и т.п.). Сетевые средства информационного коммутатора предназначены для осуществления обмена данными в сети и соответствуют транспортному уровню вышеизложенной МПД. Сетевые средства включают в себя, но не в ограничительном смысле, интерфейсную сетевую плату(ы), драйвера устройств, сетевые протоколы. Предпочтительно, в совокупности сетевые средства информационного коммутатора реализуют обмен данными согласно широко известному стеку протоколов TCP/IP. В контексте настоящего изобретения, запоминающее устройство информационного коммутатора предназначено для хранения конфигурационных данных информационного коммутатора и буферизации сообщений в соответствии с концепциями, реализуемыми сетью информационной коммутации. Запоминающее устройство может представлять собой любую предпочтительную совокупность известных запоминающих устройств, таких как, например, ПЗУ, ОЗУ, модули флэш-памяти, накопители на жестких дисках. Кроме того, запоминающее устройство информационного коммутатора может хранить и другие данные и средства, (например, операционную систему), при этом хранящиеся на информационном коммутаторе данные могут в разные моменты времени находиться в разных из вышеперечисленных запоминающих устройств.- 15006307 В соответствии с вышесказанным, на основе информации о маршрутах, добавленной к ГТК сети информационной коммутации, конфигурационные данные этой сети можно разделить на части и сохранить на каждом из ее информационных коммутаторов только соответствующую ему часть конфигурационных данных. В предпочтительном варианте осуществления, на информационном коммутаторе сохраняют только те записи ГТК сети информационной коммутации, которые соответствуют маршруту, в котором задействован этот информационный коммутатор, а также все другие данные, ассоциированные с этими записями, если таковые данные имеются. В результате, конфигурационные данные информационного коммутатора, хранящиеся в запоминающем устройстве из его состава, содержат локальную таблицу коммутации (ЛТК), соответствующую упомянутой части ГТК сети информационной коммутации (ГТК). Каждая запись ЛТК содержит уникальный адрес (адресную пару) приложения-отправителя и уникальный адрес (адресную пару) получателя, являющегося локальным для рассматриваемого информационного коммутатора, и имеет вид SiPj DkPl, где Dk соответствует РМТ-адресу приложения-получателя (Sk) в случае, если локальным получателем сообщения является приложение-получатель, или соответствует РМТ-адресу Кk другого информационного коммутатора, которому должно быть передано указанное сообщение для дальнейшей коммутации по заданному маршруту. Следует отметить, что структура ЛТК такова, что в каждой записи адрес приложения-отправителя позволяет однозначно определить адрес локального получателя информационного коммутатора. Указанная структура ЛТК является наиболее предпочтительной, но также возможны варианты ее реализации,при которых адреса локальных получателей могут однозначно определяться из других параметров, связанных с заданным маршрутом передачи сообщения. Таким образом при таком представлении ГТК сети информационной коммутации в виде совокупности ЛТК информационных коммутаторов в каждом из заданных маршрутов для первого информационного коммутатора в этом маршруте локальным отправителем является приложение-отправитель, для последнего информационного коммутатора в этом маршруте локальным получателем является приложение-получатель, а при наличии в этом маршруте одного или более промежуточных (транзитных) информационных коммутаторов локальным отправителем и локальным получателем для этих транзитных информационных коммутаторов будут соответствующие другие информационные коммутаторы этого маршрута. Специалистам в данной области техники следует понимать, что вышеизложенная организация конфигурационных данных информационных коммутаторов в виде ЛТК является предпочтительной, но не обязательной. В частности, при использовании в сети информационной коммутации для характеризации информационных связей между приложениями структуры данных, отличной от ГТК, каждый из информационных коммутаторов этой сети будет содержать соответствующую ему часть этой структуры. Если конфигурационные данные сети информационной коммутации хранят также и другие данные,например, время актуальности ПИОС и тип информационной связи, то конфигурационные данные информационного коммутатора, являющиеся, по существу частью упомянутых конфигурационных данных сети информационной коммутации, будут также включать в себя для каждого адреса приложенияотправителя в ЛТК время актуальности ПИОС, регламентирующее время нахождения ПИОС в сети информационной коммутации, и тип информационной связи. Также соответствующий настоящему изобретению информационный коммутатор содержит логические средства, реализующие основные функции информационного коммутатора по коммутации сообщений в сети информационной коммутации. В частности, эти логические средства могут представлять собой программные средства, хранящиеся на запоминающем устройстве из состава информационного коммутатора в виде машиноисполняемых команд, и устройство обработки данных для исполнения этих машиноисполняемых команд. Также логические средства могут представлять собой аппаратные средства, либо любую известную комбинацию аппаратных и программных средств. Помимо этого, логические средства могут представлять собой единый элемент информационного коммутатора, либо набор его элементов. Поскольку, как сказано ранее, информационный коммутатор функционирует на уровне РМТ, его логические средства, естественно, выполнены с возможностью формирования, приема, отправки и обработки служебных сообщений уровня РМТ, представляющих собой вышеописанные пакеты ПУПС. В соответствии с соответствующей настоящему изобретению концепцией коммутации сообщений,логические средства информационного коммутатора выполнены с возможностью организации одного или более буферов для сообщений в запоминающем устройстве информационного коммутатора. Организация буферов может быть реализована любыми подходящими способами и средствами, известными из уровня техники, например, посредством вызова соответствующих процедур операционной системы информационного коммутатора. Для более эффективного функционирования информационного коммутатора организация буферов предпочтительна на запоминающих устройствах с более быстрым доступом(например, ОЗУ). В предпочтительном варианте осуществления логические средства организуют статический буфер для каждого локального получателя, адрес которого содержится в ЛТК. Однако логические средства могут осуществлять и динамическую организацию буферов.- 16006307 Логические средства информационного коммутатора также выполнены с возможностью определения адреса приложения-отправителя из принятого от локального отправителя сообщения. В соответствии с вышесказанным, изначально при формировании сообщения, пересылаемого от приложенияотправителя в сеть информационной коммутации, соответствующий этому приложению-отправителю ИК-стек добавляет в его заголовок адресную пару приложения-отправителя. Поэтому, зная формат заголовка передаваемого сообщения, логические средства известным из уровня техники способом выполняют разбор заголовка принятого сообщения и извлекают адресную пару приложения-отправителя. Следует отметить, что по своей сути ПИО-порт является атрибутом приложения, а не информационного коммутатора, поэтому в случае, если локальным получателем является другой информационный коммутатор, ПИО-порт локального получателя игнорируется при обработке сообщения, ибо важен только РМТадрес этого другого информационного коммутатора. В этом случае ПИО-порт может представлять собой любое незначащее число. Логические средства информационного коммутатора выполнены с возможностью определения адресов локальных получателей на основе извлеченного адреса приложения-отправителя. Для этого логические средства обращаются к ЛТК и выявляют в ней все записи, содержащие извлеченную адресную пару приложения-отправителя, и, таким образом, на основе этих записей определяют всех локальных получателей этого сообщения. Следует отметить, что у сообщения может быть более одного получателя при многоадресной коммутации. В предпочтительном варианте осуществления, в случае отсутствия в ЛТК записей, содержащих адресную пару, совпадающую с извлеченной адресной парой приложенияотправителя, логические средства формируют и посылают локальному отправителю ПУПС-ответ с информацией об ошибке и уничтожают это сообщение. Также логические средства информационного коммутатора выполнены с возможностью помещения обработанного сообщения в по меньшей мере один из упомянутых буферов. В соответствии с вышесказанным, в предпочтительном варианте осуществления буферы выделяются для всех локальных получателей, адреса которых содержатся в ЛТК. Логические средства помещают сообщение только в те буферы, которые соответствуют конкретным локальным получателям этого сообщения. При этом в предпочтительном варианте осуществления логические средства поддерживают две разновидности буферов в зависимости от вида локального получателя: если локальным получателем является приложение-получатель, то буфер, в который логические средства помещают принятое сообщение, является локальным буфером, соответствующим этому приложению-получателю, а если локальным получателем является другой информационный коммутатор, то буфер, в который логические средства помещают принятое сообщение, является транзитным буфером, соответствующим этому другому информационному коммутатору. Разница между локальным и транзитным буферами будет пояснена ниже. В соответствии с концепцией настоящего изобретения, приложения-получатели сами задают регламент получения сообщений из сети информационной коммутации и при необходимости получения этого сообщения посылают в эту сеть соответствующий запрос. Таким образом, логические средства информационного коммутатора выполнены с возможностью обработки запроса на получение буферизованного сообщения, принятого от по меньшей мере одного локального получателя, и отправки буферизованного сообщения по меньшей мере одному локальному получателю. Упомянутый запрос представляет собой ПУПС-запрос. В предпочтительном варианте осуществления, если локальным получателем является приложениеполучатель, логические средства информационного коммутатора отправляют сообщение (ПИОС) приложению-получателю из локального буфера после приема соответствующего ПУПС-запроса от этого приложения-получателя. Для обеспечения согласованного и непротиворечивого доступа к локальному буферу из многопоточного приложения логические средства информационного коммутатора выполняют блокирование этого локального буфера на чтение на время выполнения операции передачи ПИОС локальному ИК-стеку этого приложения. Блокировка обеспечивает строго последовательное чтение из локального буфера в порядке хранения ПИОС. Это производится также для того, чтобы в случае информационной связи вытесняющего типа не происходила запись в этот буфер во время его чтения приложением и, плюс к этому, чтобы не было конкуренции за один буфер между разными потоками в приложенииполучателе. При этом, если в конфигурационных данных информационного коммутатора задан тип информационной связи и коммутация ПИОС осуществляется в рамках информационной связи вытесняющего типа,то независимо для каждой адресной пары получателя SkPl хранится только последнее из полученных рассматриваемым информационным коммутатором ПИОС. Приложение Sk может получить по входящему ПИО-порту Pl только первое ПИОС из указанного локального буфера. Удаление ПИОС из локального буфера производится либо после подтверждения приложением получения соответствующего ПИОС, либо после превышения временем пребывания этого ПИОС в сети значения времени актуальности ПИОС. В предпочтительном варианте осуществления, если локальным получателем является другой информационный коммутатор, то логические средства информационного коммутатора отправляют сообщение (ПИОС) этому другому информационному коммутатору из транзитного буфера по собственной инициативе, т.е. без получения запроса от этого другого информационного коммутатора. Иными слова- 17006307 ми, в предпочтительном варианте осуществления запрос на получение буферизованного сообщения выдает только приложение-получатель, однако при желании можно реализовать коммутацию таким образом, чтобы информационные коммутаторы-получатели тоже выдавали запрос на получение буферизованного сообщения. Регламент отправки сообщений из транзитных буферов определяется, например, из соображений оптимизации сетевого трафика, обеспечивающего передачу буферизированных сообщений,и времени доставки сообщений. Специалистам в данной области техники должно быть очевидно, что в случае осуществления запроса на получение буферизованного сообщения информационным коммутатором и при отсутствии буферизованного сообщения в информационном коммутаторе-отправителе, возникает необходимость в повторном запросе со стороны информационного коммутатора-получателя. Такие повторные запросы могут существенно загружать вычислительные и транспортные ресурсы информационных коммутаторов. Из вышесказанного следует, что рассматриваемый коммутатор оперирует пакетами ПИОС и служебными пакетами ПУПС. Поэтому логические средства информационного коммутатора выполнены с возможностью определения типа любого принятого пакета уровня РМТ посредством анализа полей его заголовка, заранее обладая информацией о его формате. При этом следует отметить, что в соответствии с вышесказанным, при формировании пакета ПИОС или служебного пакета ПУПС ИК-стек заносит в его заголовок метку типа пакета. Также при формировании любого ПУПС логические средства заносят в его заголовок метку типа этого ПУПС. Конфигурационные данные информационного коммутатора для каждого приложения-отправителя могут содержать значение приоритета коммутации сообщений, задаваемое для одной или более записей упомянутой структуры данных, соответствующих этому приложению-отправителю. Это значение служит для логических средств индикатором того, что ПИОС данного приложения-отправителя должен иметь приоритет при обработке. Например, значение приоритета коммутации может предписывать, что при обработке сообщений приложения-отправителя с адресной парой S1P1 ПИОС такого приложения должны иметь приоритет перед любым другим ПИОС. Специалистам в данной области техники должно быть понятно, что могут быть реализованы и любые другие варианты интерпретации упомянутого значения приоритета для управления регламентом обслуживания информационных связей сетью информационной коммутации. Однако, предпочтительный вариант осуществления настоящего изобретения предусматривает безоговорочную приоритетность любого ПУПС перед любым ПИОС. Для случая, когда в конфигурационных данных информационного коммутатора задано время актуальности ПИОС, логические средства информационного коммутатора дополнительно выполнены с возможностью контроля времени нахождения ПИОС в сети. Метка времени, оставшегося до истечения времени актуальности ПИОС, хранится в соответствующем поле его заголовка. При обработке ПИОС логические средства извлекают этот параметр из заголовка и уничтожают ПИОС в случае, если время его нахождения в сети превышает время актуальности ПИОС. Это позволяет избежать нежелательного переполнения буферов и "блуждания" по сети потерянных сообщений. Следует отметить, что для ПУПС время актуальности в сети информационной коммутации не ограничено. Согласно вышесказанному, в соответствии с вышеизложенной моделью передачи данных система интеграции приложений, соответствующая настоящему изобретению, поддерживает блокируемый и неблокируемый режимы передачи ПИОС, при этом режим передачи задается приложением-отправителем посредством ИК-стека. В связи с этим, естественно, логические средства рассматриваемого информационного коммутатора выполнены с возможностью поддержки обоих упомянутых режимов. Как упомянуто ранее, при формировании ПИОС уровня РМТ ИК-стек заносит в соответствующее его поле метку блокируемого режима передачи. Логические средства информационного коммутатора выполнены с возможностью извлечения этой метки при анализе заголовка принятого ПИОС с целью определения того, какой режим передачи требуется реализовать для этого ПИОС. Для реализации блокируемого режима передачи логические средства информационного коммутатора выполнены с возможностью присвоения ПИОС уникальной метки блокируемой передачи, идентифицирующей конкретную передачу до каждого приложения-получателя. Это делается для того, чтобы обеспечить возможность задавать режим передачи не приложением-отправителем, а посредством изменения конфигурационных данных сети информационной коммутации. В соответствии с самой сущностью блокируемого режима передачи, логические средства информационного коммутатора выполнены с возможностью формирования и отправки подтверждений приложению-отправителю об успешных или неуспешных результатах доставки ПИОС каждому из приложенийполучателей. Также логические средства выполнены с возможностью агрегирования всех подтверждений от локальных получателей. Агрегирование реализуется посредством формирования таблицы агрегации (ТА) и сохранения ее в запоминающем устройстве информационного коммутатора. Эта таблица агрегации для каждого ПИОС,обработанного на рассматриваемом информационном коммутаторе, содержит записи о передаче этого ПИОС всем локальным получателям, информацию о локальном отправителе ПИОС и информацию о подтверждениях, полученных от локальных получателей. Записи таблицы агрегации, в частности, содержат- 18006307 поля S и Р соответствуют адресной паре отправителя ПИОС, для которого осуществляется блокируемая передача; поле М содержит метку блокируемой передачи ПИОС; поле LP содержит РМТ-адрес локального отправителя ПИОС; поле Dk соответствует локальному получателю ПИОС; поле Ack предназначено для отслеживания состояния доставки до локальных получателей. Это позволяет реализовывать многоадресную передачу сообщения (от одного приложенияотправителя многим приложениям-получателям) в блокируемом режиме передачи. Например, если был послан блокируемый ПИОС более чем одному приложению-получателю, то подтверждение приложению-отправителю об успешной доставке ПИОС приложениям-получателям будет передаваться только после того, как в таблице агрегации будут собраны подтверждения о получении от каждого приложенияполучателя. Более подробно аспекты блокируемой передачи и способ формирования ТА изложены ниже. Таким образом, в соответствии с предпочтительным вариантом настоящего изобретения, сеть информационной коммутации, являющаяся основным компонентом системы интеграции приложений, в качестве своих узлов коммутации содержит информационные коммутаторы, раскрытые выше. Как следует из вышеприведенного описания каждый из информационных коммутаторов осуществляет коммутацию сообщений независимо, исключительно на основе собственных конфигурационных данных и вспомогательной информации, содержащейся в сообщениях. Резюмируя вышеизложенное, ниже со ссылкой на фиг. 7 приведено описание основных этапов способа организации взаимодействия между множеством распределенных приложений, реализуемого предпочтительным вариантом системы интеграции приложений, соответствующей настоящему изобретению. При взаимодействии приложений в рамках конкретной информационной связи, на этапе 701 ИКстек, соответствующий приложению-отправителю, на уровне ADD получает от приложения данные,подлежащие отправке одному или более приложениям-получателям, формирует из этих данных ПИОС уровня ADD, инкапсулирует это ПИОС в РМТ-пакет (ПИОС уровня РМТ), занося в его заголовок РМТадрес приложения отправителя, ПИО-порт, соответствующий упомянутой информационной связи, и другие необходимые параметры и пересылает сформированный РМТ-пакет в сеть информационной коммутации. На этапе 702 сеть информационной коммутации на основе своих конфигурационных данных выполняет коммутацию пересланного ИК-стеком ПИОС по одному или более маршрутам, каждый из которых соответствует записи в ГТК, которая содержит адрес упомянутого приложения-отправителя, при этом сеть информационной коммутации выполняет промежуточную буферизацию упомянутого ПИОС в узлах коммутации при его коммутации. На данном этапе сеть информационной коммутации (сеть ИК) принимает пересланное ИК-стеком ПИОС посредством информационного коммутатора, для которого приложение-отправитель является локальным отправителем, причем в каждом из вышеупомянутых маршрутов этот информационный коммутатор является первым. Помимо этого, на данном этапе при коммутации ПИОС по каждому из упомянутых маршрутов каждый из образующих этот маршрут одного или более информационных коммутаторов определяет адрес приложения-отправителя из заголовка ПИОС, затем на основе собственной ЛТК и извлеченного адреса приложения-отправителя определяет одного или более локальных получателей, помещает ПИОС в надлежащий буфер (локальный или транзитный) и, если этот информационный коммутатор не является последним в этом маршруте, пересылает ПИОС далее по маршруту (из транзитного буфера). На этапе 703 каждый из ИК-стеков, соответствующих одному или более приложениямполучателям, формирует ПУПС-запрос на получение упомянутого ПИОС и посылает его в сеть информационной коммутации. На этапе 704 сеть информационной коммутации принимает и обрабатывает эти ПУПС-запросы и посылает буферизованное ПИОС каждому из ИК-стеков, соответствующих упомянутым одному или более приложениям-получателям. На данном этапе сеть информационной коммутации принимает и обрабатывает ПУПС-запрос от ИК-стека приложения-получателя посредством информационного коммутатора, для которого это приложение-получатель является локальным получателем, причем этот информационный коммутатор является последним в маршруте, соответствующем данному приложениюполучателю. Наконец, на этапе 705 каждый из ИК-стеков, соответствующих упомянутым одному или более приложениям-получателям, обрабатывает принятое от сети информационной коммутации ПИОС уровня РМТ, выполняет его деинкапсуляцию с целью получения ПИОС уровня ADD и с уровня ADD предоставляет данные соответствующему ему приложению-получателю. Ниже описаны основные фазы коммутации ПИОС уровня РМТ, реализуемые вышеизложенным предпочтительным вариантом осуществления сети информационной коммутации, соответствующей настоящему изобретению, при этом полагается блокируемый режим передачи. При изложении предполагается, что заголовок ПИОС уровня РМТ включает в себя следующие параметры:- 19006307 1. S - РМТ-адрес приложения; 2. Р - ПИО-порт; 3. F - тип РМТ пакета; 4. М - метка блокируемой передачи; 5. R - результат; 6. LS - параметр, идентифицирующий локального отправителя РМТ-пакета; 7. TTL - временной параметр, определяющий остаток времени нахождения ПИОС в сети информационной коммутации. В нижеследующем описании термин "параметр пакета" синонимичен термину "параметр заголовка". Коммутация ПИОС в сети информационной коммутации включает в себя следующие фазы: 1. Получение ПИОС информационным коммутатором 2. Коммутация ПИОС на информационном коммутаторе 3. Передача ПИОС на другой информационный коммутатор 4. Обработка запроса локального ИК-стека на передачу ПИОС 5. Обработка ПУПС квитанции на информационном коммутаторе 6. Запрос ИК-стеком подтверждения о доставке 7. Обработка ПУПС-ответов на информационном коммутаторе Каждая из этих фаз включает в себя обмен РМТ-пакетами по типу "запрос-ответ" между двумя объектами сети информационной коммутации. Первый объект передает другому объекту РМТ-пакет, являющийся в рассматриваемом обмене запросом. Второй объект направляет первому объекту РМТ-пакет как результат обработки полученного запроса, являющийся в рассматриваемом обмене ответом. Получение ПИОС информационным коммутатором Информационный коммутатор получает от локального отправителя (локального ИК-стека или другого информационного коммутатора) ПИОС, для которого определены следующие параметры:- Р - значение ПИО-порта, идентифицирующего информационную связь, в рамках которой производится передача ПИОС;- F - значение типа, соответствующее ПИОС. Дополнительно может быть определено значение параметров М, LS и TTL ПИОС. При приеме информационный коммутатор определяет и сохраняет продолжительность приема ПИОС как отрезок времени между моментами приема первого и последнего символов ПИОС. Для проверки допустимости коммутации информационный коммутатор проверяет наличие в ЛТК записей с адресной парой отправителя, совпадающей со значениями параметра S и Р исходного ПИОС. Если указанной пары не существует, то информационный коммутатор формирует и передает локальному отправителю ПУПС-ответ и уничтожает ПИОС. Для переданного ПУПС-ответа определены следующие значения параметров:- R - значение кода возврата WRONG SOURCE. При определении и проверке TTL, если значение TTL параметра ПИОС не определено или ПИОС получен от локального ИК-стека, то информационный коммутатор присваивает параметру TTL значение параметра времени актуальности ПИОС, определенного в ЛТК для данной адресной пары S и Р. Присвоение значения параметра модифицирует заголовок исходного ПИОС. Если значение TTL параметра исходного ПИОС определено, то в случае, если оно больше продолжительности приема ПИОС, то информационный коммутатор декрементирует значение TTL на значение продолжительности передачи ПИОС; в случае, если оно меньше или равно продолжительности приема ПИОС, то информационный коммутатор формирует и передает локальному отправителю ПУПС-ответ и уничтожает ПИОС. Для переданного ПУПС-ответа определены следующие значения параметров:R - значение кода возврата MESSAGE EXPIRED; М - идентификатор блокируемой передачи, определенный и равный значению параметра М исходного ПИОС, если таковой был определен. При проверке информационным коммутатором блокируемого режима передачи, если значение параметра М исходного ПИОС определено и равно 1, то информационный коммутатор генерирует уникальную метку блокируемой передачи и присваивает ее параметру М. Затем при завершении фазы получения ПИОС информационный коммутатор присваивает значение РМТ-адреса локального отправителя параметру LS, модифицируя заголовок исходного ПИОС. Информационный коммутатор формирует и передает локальному отправителю ПУПС-ответ, для которого определены следующие значения параметров:R - значение кода возврата SUCCESS; М - идентификатор блокируемой передачи, определенный и равный значению параметра М исходного ПИОС, если таковой был определен, в том числе и после модификации. Информационный коммутатор фиксирует локальное время приема ПИОС. Коммутация ПИОС на информационном коммутаторе Коммутация ПИОС на информационном коммутаторе происходит после этапа получения ПИОС вне зависимости от того, что является локальным отправителем: ИК-стек или другой информационный коммутатор. Условием коммутации ПИОС на информационном коммутаторе является наличие в его ЛТК записей SiPj - DkPl, где Si и Рj совпадает со значениями параметров S и Р исходного ПИОС. При формировании ТА, если значение М заголовка ПИОС определено и отлично от 0 и 1, то для каждой записи SiPj -DkPl в ЛТК, в которой Si и Рj совпадает со значениями S и Р ПИОС, создается запись в таблице агрегации, например, в формате (S, Р, М, LP, Dk, Ack), где 1. значение LP соответствует значению LS из заголовка ПИОС; 2. значения Dk берется из соответствующей записи в ЛТК; 3. значение Ack устанавливается в значение 0. Для каждой пары SiРj - DkPl ЛТК, у которой Si и Рj совпадают со значениями S и Р ПИОС, осуществляется распределение по локальным получателям, при этом создается копия ПИОС, которая помещается в локальный буфер, определенный для рассматриваемой адресной пары DkPl, если Dk является РМТадресом локального для рассматриваемого информационного коммутатора приложения, при этом, если передача имеет место в рамках информационной связи вытесняющего типа, то для рассматриваемого локального буфера адресной пары получателя DkPl, выполняются следующие действия: 1. если буфер заблокирован, то ожидается его разблокировка; 2. разблокированный буфер блокируется; 3. производится очистка заблокированного буфера; 4. в буфер помещается указанная ранее копия ПИОС; 5. буфер разблокируется;- помещается в соответствующий транзитный буфер, если Dk является РМТ-адресом другого информационного коммутатора. Для каждого первого ПИОС в локальном буфере выполняется очистка заблокированного локального буфера с помощью выполнения следующих действий: 1. если ПИОС имеет значение параметра М, определенное и отличное от 1 и 0, производится формирование ПУПС-квитанции для собственной обработки информационным коммутатором. Процесс обработки ПУПС-квитанции описан ниже. Для указанной ПУПС-квитанции определены следующие параметры заголовка:S, Р, М - значения соответствующих параметров рассматриваемого ПИОС;- R - результат блокируемой передачи FAIL; 2. рассматриваемый ПИОС удаляется из буфера. Очистка буфера выполняется, пока буфер не окажется пустым. Передача ПИОС на другой информационный коммутатор Передача на другой информационный коммутатор осуществляется только того ПИОС, который должен быть передан согласно локальной таблице коммутации на другой информационный коммутатор и находится в транзитном буфере, т.е. для него уже осуществлена коммутация. Для отправляемого ПИОС пересчитывается TTL как разница между текущим значением TTL и продолжительностью хранения рассматриваемого ПИОС на информационном коммутаторе. При нулевом или отрицательном значении TTL выполняются следующие действия: 1. если ПИОС имеет значение параметра М, определенное и отличное от 1 и 0, производится формирование ПУПС-квитанции для собственной обработки информационным коммутатором. Процесс обработки ПУПС-квитанции описан ниже. Для указанной ПУПС-квитанции определены следующие параметры заголовка:S, Р, М - значения соответствующих параметров рассматриваемого ПИОС;- R - результат блокируемой передачи FAIL; 2. рассматриваемый ПИОС удаляется. При положительном вычисленном значении TTL оно присваивается соответствующему параметру рассматриваемого ПИОС. Информационный коммутатор передает локальному получателю рассматриваемого ПИОС собственно ПИОС и получает от него ПУПС-ответ. Обработка ПУПС-ответа приведена ниже.- 21006307 Если во время передачи на транспортном уровне возникает ошибка передачи ПИОС либо ошибка приема ПУПС-ответа, информационный коммутатор повторяет процедуру передачи, включая повторное вычисление TTL. Обработка запроса локального ИК-стека на передачу ПИОС Запрос от ИК-стека на передачу ПИОС поступает в информационный коммутатор в виде ПУПСзапроса, в заголовке которого определены следующие параметры:S - собственное значение РМТ-адреса приложения получателя ПИОС; Р - значение ПИО-порта, идентифицирующего информационную связь, в рамках которой производится получение ПИОС;F - значение типа, соответствующее ПУПС-запросу. Если локальный буфер, ассоциированный с адресом S, Р данного ПУПС-запроса, не заблокирован,то он на данном этапе блокируется, в противном случае, исходный ПУПС-запрос ожидает разблокирования буфера. Для каждого первого ПИОС в локальном буфере пересчитывается TTL как разница между текущим значением TTL и продолжительностью хранения рассматриваемого ПИОС на информационном коммутаторе. При нулевом или отрицательном значении TTL выполняются следующие действия: 1. если ПИОС имеет значение параметра М, определенное и отличное от 1 и 0, производится формирование ПУПС-квитанции для собственной обработки информационным коммутатором. Процесс обработки ПУПС-квитанции описан ниже. Для указанной ПУПС-квитанции определены следующие параметры заголовка:S, Р, М - значения соответствующих параметров рассматриваемого ПИОС;R - результат блокируемой передачи FAIL; 2. рассматриваемый ПИОС удаляется из буфера. При положительном вычисленном значении TTL оно присваивается соответствующему параметру рассматриваемого ПИОС. Очистка буфера выполняется, пока буфер не окажется пустым либо пока первое ПИОС в буфере не будет иметь ненулевое вычисленное TTL. При передаче ответа на запрос, если в локальном буфере, ассоциированном с адресной парой (S; Р) заголовка ПУПС-запроса, есть ПИОС, то информационный коммутатор 1. модифицирует параметры S и Р копии рассматриваемого ПИОС, устанавливая их в значения S и Р принятого ПУПС-запроса; 2. передает модифицированную копию ИК-стеку принимающего приложения. Если передача ПИОС завершилась успешно и параметр М запрошенного ПИОС отличен от 0 и 1, то информационный коммутатор формирует для собственной обработки ПУПС-квитанцию, у которой определены следующие параметры:S, Р - значения соответствующих параметров переданного ПИОС;F - значение типа, соответствующее ПУПС-квитанции; М - значение соответствующего параметра заголовка переданного ПИОС;R - результат блокируемой передачи SUCCESS. В случае успешной передачи исходный ПИОС удаляется из локального буфера. Если локальный буфер, ассоциированный с адресной парой (S; Р) ПУПС-запроса, пуст, информационный коммутатор передает ИК-стеку ПУПС-ответ, в котором определены параметры заголовка:R - значение кода возврата NO DATA. После завершения отправки ПИОС либо ПУПС-ответа информационный коммутатор снимает с данного локального буфера блокировку. Обработка ПУПС-квитанций на информационном коммутаторе ПУПС-квитанция либо формируется самим информационным коммутатором для собственной обработки, либо поступает от другого информационного коммутатора. В заголовке ПУПС-квитанции определены следующие параметры:S - значение РМТ-адреса отправителя ПИОС; Р - значение ПИО-порта, идентифицирующего информационную связь, в рамках которой производилось передача ПИОС;R - результат блокируемой передачи ("SUCCESS" или "FAIL"); М - метка блокируемой передачи;LS - РМТ-адрес локального отправителя ПУПС-квитанции или РМТ-адрес приложения-получателя для локально сформированной ПУПС-квитанции.- 22006307 После обработки исходная ПУПС-квитанция удаляется. При получении ПУПС-квитанции от локального информационного коммутатора выполняется первичная обработка ПУПС-квитанции. Если в ТА отсутствует запись, у которой значения полей S, Р, М, Dk совпадают со значениями S, Р,М, LS полученной квитанции или значение поля Ack в случае совпадения не равно "0", то информационный коммутатор формирует и передает локальному отправителю ПУПС-квитанции ПУПС-ответ, в котором определены параметры заголовкаR - значение кода возврата FAIL. В противном случае информационный коммутатор формирует и передает локальному отправителю исходной ПУПС-квитанции ПУПС-ответ, в котором значения S и F те же, аR представляет собой значение кода возврата SUCCESS. В случае ошибки блокируемой передачи, значение параметра R ПУПС-квитанции содержит значение FAIL, в этом случае информационный коммутатор формирует агрегирующую ПУПС-квитанцию. В заголовке сформированной ПУПС-квитанции определены следующие параметры:S - соответствующее значение записи таблицы агрегации; Р - соответствующее значение записи таблицы агрегации;R - результат блокируемой передачи FAIL; М - метка блокируемой передачи;LS - идентификатор локального отправителя. В случае успешной блокируемой передачи значение параметра R ПУПС-квитанции содержит значение SUCCESS, в этом случае в записи ТА, у которой значения (S, Р, М, Dk) совпадают со значениямиS, Р, М, LS параметров исходной ПУПС-квитанции, значения поля Ack устанавливается в 1. Если у всех записей ТА, у которой значения (S, Р, М) совпадают со значениями S, Р, М исходной ПУПС-квитанции,все значения Ack равны 1, то информационный коммутатор формирует агрегирующую ПУПСквитанцию, у которой определены следующие параметры:S - соответствующее значение записи таблица агрегации; Р - соответствующее значение записи таблица агрегации;R - результат блокируемой передачи SUCCESS; М - метка блокируемой передачи;LS - идентификатор локального отправителя. При обработке агрегирующей ПУПС-квитанции для агрегирующей ПУПС-квитанции определяется получатель. РМТ-адрес получателя соответствует значению LP из соответствующей записи ТА. В этом случае все записи ТА с полями (S, P, M, LP) удаляются. Если получателем ПУПС-квитанции является другой информационный коммутатор, то ПУПСквитанция передается ему. Если получателем ПУПС-квитанции является локальный ИК-стек, то ПУПС-квитанция ожидает запроса на подтверждения доставки. Запрос ИК-стеком подтверждения о доставке Запрос от ИК-стека подтверждения доставки ПИОС поступает в информационный коммутатор в виде ПУПС-запроса квитанции, в заголовке которого определены следующие параметры:S - собственное значение РМТ-адреса приложения получателя ПИОС; Р - значение ПИО-порта, идентифицирующего информационную связь, в рамках которой производится получение ПИОС;F - значение типа, соответствующее ПУПС-запросу квитанции; М - метка блокируемой передачи. При наличии у информационного коммутатора агрегирующей ПУПС-квитанции, чьи параметры S,Р, М идентичны соответствующим параметрам ПУПС-запроса квитанции, информационный коммутатор передает ИК-стеку агрегирующую ПУПС-квитанцию. При отсутствии у информационного коммутатора описанной выше агрегирующей ПУПСквитанции формируется и передается ИК-стеку ПУПС-ответ, в котором определены параметры заголовка:R - значение кода возврата NO DATA. Обработка ПУПС-ответов на информационном коммутаторе ПУПС-ответы поступают на информационный коммутатор от другого информационного коммутатора после передачи последнему либо ПИОС, либо ПУПС-квитанций. В заголовке ПУПС-ответа определены следующие параметры:R - значение кода возврата. Правила обработки ПУПС-ответа при передаче ПИОС заключаются в следующем. ПУПС-ответы со значением R SUCCESS, полученные при передаче ПИОС, приводят к удалению из транзитного буфера переданного ПИОС. Если при передаче ПИОС с определенным параметром М, отличным от 0 и 1, был получен ПУПСответ со значением параметра R, отличным от SUCCESS, то информационный коммутатор формирует для собственной обработки ПУПС-квитанцию, у которой определены следующие параметры:S и Р - значения соответствующих параметров переданного ПИОС;F - значение типа, соответствующее ПУПС-квитанции; М - значение соответствующего параметра заголовка переданного ПИОС;R - результат блокируемой передачи FAIL. Реализация передачи и приема ПИОС уровня ADD на уровне РМТ При передаче ПИОС уровня ADD приложение определяет: 1. ПИО-порт Р, в качестве идентификатора связи, в рамках которого передается ПИОС; 2. режим передачи в качестве блокируемого или неблокируемого; При передаче ПИОС уровня РМТ ИК-стек формирует и передает на локальный информационный коммутатор ПИОС уровня РМТ, параметры которого принимают следующее значения:F - значение типа, соответствующее ПИОС; М - значение, равное 1, если режим передачи блокируемый, и 0, если режим передачи неблокируемый. Если значение R полученного ПУПС-ответа отлично от SUCCESS, то передача считается несостоявшейся. Если значение R определено как SUCCESS и если режим передачи неблокируемый, то передача считается завершенной. Если значение R определено как SUCCESS и если режим передачи блокируемый, то ИК-стек получает из параметра значение М ПУПС-ответа, как метки совершаемой блокируемой передачи, и осуществляет завершение блокируемой передачи. В случае завершения блокируемой передачи ИК-стек периодически выдает на локальный информационный коммутатор запрос подтверждения о доставке. Формируемый и отправляемый ПУПС-запрос квитанции содержит следующие определенные параметры:S - собственное значение РМТ-адреса; Р - значение ПИО-порта, идентифицирующего информационную связь, в рамках которой была произведена посылка ПИОС;F - значение типа, соответствующее ПУПС-запросу квитанции; М - метка блокируемой передачи, переданная ранее через ПУПС-ответ. В случае, если информационный коммутатор передал в ответ на запрос ПУПС-квитанцию, то при значении параметра R SUCCESS передача ПИОС считается завершенной, при значении, отличном отSUCCESS, передача считается несостоявшейся. Если информационный коммутатор передал ПУПС-ответ, то передача считается незавершенной и ИК-стек продолжает опрашивать локальный информационный коммутатор до получения ПУПСквитанции или до истечения периода ожидания. Опрос локального информационного коммутатора может быть завершен по каким-либо внутренним для ИК-стека причинам, например, при наличии ограничения на время проведения запросов. При приеме ПИОС уровня ADD приложение определяет: 1. ПИО-порт Р как идентификатор связи, в рамках которого передается ПИОС; 2. режим передачи (блокируемый или неблокируемый). При получении ПИОС уровня РМТ ИК-стек формирует и передает на локальный информационный коммутатор ПУПС-запрос, параметры которого принимают следующее значение:F - значение типа, соответствующее ПУПС-запросу. Если полученный от информационного коммутатора РМТ-пакет является ПИОС уровня РМТ, то ИК-стек осуществляет подтверждение приема этого ПИОС. Если полученный от информационного коммутатора РМТ-пакет является ПУПС-ответом с результатом "NO DATA", то для данного приложения по указанному порту на локальном информационном коммутаторе нет ПИОС уровня РМТ. Получение считается завершенным с отрицательным результатом. По получении ПИОС уровня РМТ ИК-стек подтверждает факт получения, отправляя на информационный коммутатор ПУПС-запрос, параметры которого определены как:S - собственное значение РМТ-адреса приложения, подтверждающего получение ПИОС уровня РМТ; Р - значение ПИО-порта, идентифицирующего информационную связь, в рамках которой был получен подтверждаемый ПИОС уровня РМТ;R - значение, определенное как SUCCESS. Как было отмечено ранее, согласно настоящему изобретению управление взаимодействием приложений осуществляется посредством надлежащей модификации конфигурационных данных сети информационной коммутации. Для управления взаимодействием приложений соответствующая предпочтительному варианту настоящего изобретения сеть информационной коммутации содержит средства конфигурирования, выполненные с возможностью осуществления непосредственной или опосредованной связи с каждым информационным коммутатором. В предпочтительном варианте осуществления средства конфигурирования являются единой системой управления. Система управления может представлять собой обычный подключенный к сети компьютер с известными устройствами ввода (мышь, клавиатура и т.п.) и вывода (дисплей). Предпочтительно система управления хранит полную копию конфигурационных данных сети информационной коммутации, включая ГТК, например в запоминающих устройствах упомянутого компьютера. Например, при добавлении новой информационной связи (нового взаимодействия) между приложениями, включая подсоединение нового приложения, оператор может посредством ручного ввода или средств графического пользовательского интерфейса добавить новые записи в ГТК из состава хранящейся в системе управления полной копии конфигурационных данных сети информационной коммутации,задать для этих записей надлежащие маршруты и задать параметры коммутации, такие как, например,время актуальности ПИОС или тип информационной связи, в упомянутой копии конфигурационных данных. Далее система управления выполняет репликацию внесенных оператором изменений в конфигурационные данные задействуемых этими изменениями информационных коммутаторов, образующих упомянутые маршруты. При этом система управления заносит соответствующие новые записи в ЛТК упомянутых информационных коммутаторов. Репликация может быть выполнена, например, посредством команд известного специализированного протокола. На время выполнения обновления конфигурационных данных информационные коммутаторы приостанавливают основную работу по коммутации сообщений. Аналогичным образом, систему управления можно использовать для первоначального формирования конфигурационных данных информационных коммутаторов на основе конфигурационных данных сети коммутации данных в соответствии с предпочтительным вариантом осуществления настоящего изобретения. При удалении существующей информационной связи (существующего взаимодействия) между приложениями, включая отключение приложения от системы интеграции приложений, оператор может посредством ручного ввода или средств графического пользовательского интерфейса отыскать в ГТК из состава хранящейся в системе управления упомянутой полной копии конфигурационных данных записи,соответствующие этой информационной связи, и определить для этих записей надлежащие маршруты в упомянутой полной копии конфигурационных данных. Далее система управления обновляет конфигурационные данные информационных коммутаторов,образующих упомянутые маршруты, удаляя при этом соответствующие этим маршрутам записи из ЛТК этих информационных коммутаторов и ассоциированную с ними информацию из их конфигурационных данных. После этого система управления удаляет ранее найденные записи из ГТК, а также удаляет ассоциированную с ними информацию о маршрутах. На время выполнения обновления конфигурационных данных информационные коммутаторы приостанавливают основную работу по коммутации сообщений. При этом система управления обеспечивает возможность модификации ЛТК информационных коммутаторов асинхронно по отношению к этим информационным коммутаторам. Возможны и другие конкретные варианты реализации системы управления, например, предусматривающие распределение упомянутых функций управления интеграцией приложений по информационным коммутаторам, входящим в состав сети информационной коммутации. Также в контексте настоящего изобретения предусмотрены варианты реализации системы управления, обеспечивающие выборочное и неупорядоченное во времени изменение конфигурационных данных информационных коммутаторов,входящих в сеть информационной коммутации. Далее со ссылкой на фиг. 8 иллюстрируется конкретный пример интеграции приложений посредством соответствующей настоящему изобретению системы интеграции приложений. Пусть новое приложение S1, выполняющееся на Компьютере 1, подключается к системе интеграции приложений с целью взаимодействия с уже подключенными к данной системе приложениями S2 и S3,выполняющимися на Компьютере 3 и Компьютере 2, соответственно. Предположим, что при этом взаимодействии приложение S1 должно посылать данные в виде сообщений приложениям S2 и S3. Если приложение S1 изначально не содержит ИК-стек, то для взаимодействия с сетью информационной коммута- 25006307 ции ему обеспечивают ИК-стек. Чтобы приложение S1, представляемое на уровне РМТ соответствующим ему ИК-стеком, было адресуемым объектом уровня РМТ, ему ставится в соответствие по меньшей мере одна адресная пара (S1; Рk). Интегрирование приложений S1, S2 и S3 производится системой управления сети информационной коммутации (СУ ИК) независимо от самих приложений посредством задания между ними по меньшей мере одной информационной связи. Например, между приложениями S1, S2 и S3 может быть задана одна информационная связь, либо между этими приложениями можно создать две информационных связи и при этом приложения S1, S2 и S1, S3 будут взаимодействовать независимо. Для этого в ГТК, хранящейся в СУ ИК, создают соответствующие вышеупомянутым информационным связям новые записи, содержащие адресную пару приложения S1 в качества адреса приложенияотправителя и адресные пары приложений S2 и S3 в качестве адресов приложений-получателей, а также связывают с этими записями соответствующие маршруты. Специалистам в данной области техники должно быть понятно, что с упомянутыми записями при необходимости можно связать и другие параметры, например, время актуальности ПИОС. В рассматриваемом примере, поскольку приложения S1 и S3 являются локальными по отношению к информационному коммутатору ИK1, то маршрут, соответствующий добавленной записи (S1;P1) - (S3;P1),образован одним информационным коммутатором ИK1. В то же время, приложение S2 является локальным по отношению к информационному коммутатору ИК 2, следовательно, маршрут, соответствующий добавленной записи (S1;P1) - (S2;P1), образован двумя информационными коммутаторами ИK1 и ИК 2. После этого СУ ИК приостанавливает работу ИK1 и ИК 2 по коммутации ПИОС и заносит в ЛТК ИK1 две новых записи (S1;P1) - (S3;P1) и (S1;P1) - (КИК 2;Р 1), где КИК 2 - РМТ-адрес ИК 2, а в ЛТК ИК 2 - одну новую запись (S1;P1) - (S2;P1). Исключение, например, приложения S3 из множества получателей (например, полное его удаление из системы) не влечет за собой даже минимальных изменений приложения S1. При этом только изменяется ГТК СУ ИК и, как следствие, ЛТК ИK1. Еще одним аспектом настоящего изобретения является обеспечение отказоустойчивости при коммутации сообщений в сети информационной коммутации, соответствующей настоящему изобретению. Из вышеприведенного описания следует, что предлагаемая система интеграции приложений будет эффективной лишь в том случае, если каждый информационный коммутатор в сети информационной коммутации будет характеризоваться высокой отказоустойчивостью, поскольку выход из строя даже одного из них выведет из строя весь маршрут, а следовательно, и целую информационную связь. В соответствии с этим аспектом предложена специальная конфигурация узла коммутации сети информационной коммутации, называемая отказоустойчивым узлом коммутации (ОУК). ОУК состоит из связанных между собой основного информационного коммутатора (ОИК) и резервного информационного коммутатора (РИК). В рабочем режиме ОУК ОИК выполняет коммутацию РМТ-пакетов, а РИК находится в неактивном состоянии. В случае отказа ОИК происходит переключение ОУК на РИК (переключение на резерв), в результате которого ОИК отключается, РИК назначается основным и начинает выполнять коммутацию РМТ-пакетов, при этом отключения ОУК не выполняется. ОУК обеспечивает защиту от отказов, связанных, например, с выходом всего либо части оборудования из строя, нарушением целостности общесистемного или прикладного программного обеспечения,нарушением целостности данных информационного коммутатора. На уровне РМТ ОУК представляет собой единый узел коммутации РМТ-пакетов независимо от режима работы. Атрибуты ОУК как узла коммутации, например РМТ-адрес, IP-адрес, конфигурационные данные в своей части, обеспечивающей коммутацию сообщений, не изменяются при переключении на резерв. В связи с этим для других узлов коммутации сети информационной коммутации и приложений сбой ОУК и переключение на резерв внешне неотличимы от простого перезапуска узла коммутации. Для реализации ОИК и РИК, являющихся компонентами ОУК, вышеописанный информационный коммутатор необходимо оснастить дополнительными средствами. Во-первых, каждый из ОИК и РИК должен содержать хранилище данных, представляющее собой подсистему информационного коммутатора, обеспечивающее хранение данных и управление данными,которые используются при работе информационного коммутатора и сохраняются в информационном коммутаторе при его перезагрузке и выключении. В состав указанных данных входят, в частности, ПИОС, содержимое локальных и транзитных буферов, некоторые параметры функционирования информационного коммутатора. Предпочтительно, все данные в хранилище представлены в виде одной или более таблиц. Для других подсистем информационного коммутатора хранилище данных предоставляет единый универсальный программный интерфейс, обеспечивающий выполнение функций чтения, изменения, добавления и удаления данных. Во-вторых, каждый из ОИК и РИК должен содержать подсистему восстановления после отказа,предназначенную для обеспечения отказоустойчивой работы информационного коммутатора, при этом подсистемы восстановления после отказа ОИК и РИК отличаются. Подсистема восстановления после отказа также относится к логическим средствам информационного коммутатора и, по аналогии, может- 26006307 быть реализована в виде программных средств, специализированных аппаратных средств или их комбинации любым известным из уровня техники способом. В случае ОИК подсистема восстановления после отказа содержит модуль мониторинга, выполненный с возможностью периодической посылки контрольного сигнала через заранее заданный интервал времени, и модуль синхронизации ОИК, предназначенный для обеспечения синхронизации хранилища данных и выполненный с возможностью формирования и посылки команд репликации. В соответствии с вышесказанным, подсистема восстановления после отказа из состава РИК выполнена с возможностью поддержания неактивного состояния этого информационного коммутатора, при этом в неактивном состоянии информационный коммутатор не осуществляет коммутацию сообщений, а только обрабатывает принимаемую сигнальную служебную информацию от ОИК. Подсистема восстановления после отказа РИК содержит модуль синхронизации РИК, также предназначенный для обеспечения синхронизации хранилища данных, и модуль переключения на резерв, предназначенный для вывода РИК из неактивного состояния с целью замещения вышедшего из строя ОИК. Более подробно принцип работы ОИК и РИК в составе ОУК, а также их подсистем восстановления после отказа, описаны далее. Отказоустойчивость ОУК достигается посредством 1. поддержания хранилищ данных ОИК и РИК в синхронном состоянии на любой момент времени; 2. перевода РИК в активное состояние при отказе ОИК. В соответствии с вышесказанным, эти функции реализуются подсистемами восстановления после отказа ОИК и РИК. Следует отметить, что при предпочтительной организации данных в хранилищах данных РИК и ОИК в виде таблиц каждой записи в таблицах ставится флаг синхронизации, назначение которого пояснено ниже. ОУК поддерживает следующие режимы функционирования: 1. полная начальная синхронизация, предназначенная для подготовки рабочего режима ОУК; 2. рабочий режим с инкрементальной синхронизацией, позволяющий синхронизировать хранилища данных ОИК и РИК коммутаторов в процессе работы ОУК; 3. переключение на резерв, при котором осуществляется перевод РИК в активное состояние при отказе ОИК; 4. рабочий режим без синхронизации, во время которого выполняется восстановление отказавшего ОИК; 5. полная динамическая синхронизация, позволяющая выполнить полную синхронизацию хранилищ данных РИК и ОИК, не прерывая работу ОУК по коммутации сообщений. Во время работы ОУК режимы функционирования последовательно сменяют друг друга, составляя следующий типовой технологический цикл: 1. полная начальная синхронизация; 2. рабочий режим с инкрементальной синхронизацией; 3. переключение на резерв при отказе ОИК; 4. рабочий режим без синхронизации (во время которого выполняется ремонт ОИК или его замена на новый); 5. подключение отремонтированного ОИК; 6. рабочий режим с полной динамической синхронизацией; 7. рабочий режим с инкрементальной синхронизацией. Приведенный цикл показывает, что отказ ОИК не приводит к перерыву в работе ОУК, причем ремонт отказавшего ОИК и восстановление первоначальной конфигурации ОУК не требует приостановки работы ОУК в целом. Схема технологического цикла ОУК представлена на фиг. 9. Далее приводится подробное описание функционирование ОУК в вышеперечисленных режимах. Полная начальная синхронизация Режим начальной синхронизации предназначен для первичной настройки ОУК. В этом режиме ОУК остановлен. Синхронизация осуществляется полным копированием хранилища данных ОИК на РИК. После выполнения начальной синхронизации ОУК переводится в режим инкрементальной синхронизации. Инкрементальная синхронизация в рабочем режиме Режим инкрементальной синхронизации позволяет синхронизировать содержимое хранилищ данных в процессе работы ОУК путем выполнения одинаковых изменений данных в ОИК и РИК. Режим инкрементальной синхронизации является основным режимом работы ОУК. В этом режиме 1. ОИК находится в активном состоянии, обеспечивая коммутацию РМТ-пакетов и хранение данных информационного коммутатора; 2. РИК находится в неактивном состоянии; 3. модуль синхронизации ОИК принимает запросы от всех подсистем на изменение данных и осуществляет пересылку запросов локальному хранилищу данных и модулю синхронизации РИК. На РИК- 27006307 запросы на изменение данных поступают в виде команд репликации по специальному протоколу передачи данных; 4. модуль мониторинга ОИК через заданный временной интервал посылает контрольный сигнал модулю переключения на резерв РИК; 5. модуль синхронизации РИК принимает команды репликации и соответствующим образом изменяет данные в собственном локальном хранилище данных; 6. при отсутствии контрольного сигнала от ОИК, что служит признаком его отказа, модуль переключения на резерв РИК реализует переключение на резерв. Следует отметить, что инкрементальная синхронизация выполняется только для тех записей таблиц хранилища данных, у которых установлен флаг синхронизации. Переключение на резерв В режиме переключения на резерв осуществляется перевод РИК в активное состояние. ОУК переходит в режим переключения на резерв в случае неполучения РИК в течение заранее заданного интервала времени упомянутого контрольного сигнала от ОИК. В этом режиме 1. ОИК считается отключенным; 2. РИК останавливает работу модуля синхронизации и прекращает прием сигнальной информации; 3. модуль переключения на резерв РИК переводит в активное состояние, в результате чего на РИК осуществляется активация коммутации РМТ-пакетов, производится активация интерфейсов передачи данных между РИК и остальными объектами системы интеграции приложений, и РИК становится ОИК,то есть начинает обеспечивать коммутацию РМТ-пакетов в полном объеме; 4. после выполнения ремонта и подключения к ОУК отказавшего ОИК ОУК может быть переведен в режим полной динамической синхронизации. Полная динамическая синхронизация Режим полной динамической синхронизации (ПДС) позволяет выполнить полную синхронизацию хранилищ данных, не прерывая работу ОУК по коммутации сообщений. ПДС выполняется одновременно с процессом инкрементальной синхронизации. ПДС работает по следующему алгоритму: 1. сбрасывается флаг синхронизации у всех записей на РИК, замещающем ОИК; 2. на РИК, замещающем ОИК, запускается процесс синхронизации, который по очереди обходит все записи всех таблиц и для каждой записи генерирует команду репликации и устанавливает флаг синхронизации, при этом команды репликации передаются на восстановленный и вновь включенный в работу информационный коммутатор (бывший ОИК); 3. для новых записей, которые добавляются в хранилище данных другими подсистемами информационного коммутатора, на РИК, замещающем ОИК, так же генерируется команда репликации и устанавливается флаг синхронизации; 4. режим ПДС завершается, когда все записи хранилища данных имеют установленный флаг синхронизации на РИК, замещающем ОИК. После завершения ПДС продолжает работать процесс инкрементальной синхронизации в рабочем режиме. Максимальная продолжительность процесса полной динамической синхронизации зависит от текущего объема хранилища данных и средней загрузки ОУК. Учтем следующие соображения: 1. в рабочем режиме информационный коммутатор в среднем принимает столько же сообщений,сколько передает; 2. скорость передачи в среднем в два раза больше скорости приема при одинаковой загрузке дисковой подсистемы. Следовательно, при одновременном приеме и передаче сообщений скорость приема составляет 2/3 от максимальной скорости приема. Если скорость обработки команд репликации на РИК приблизительно равна максимальной скорости приема сообщений, скорость обработки команд полной репликации составит не менее 1/3 максимальной скорости приема. Продолжительность Т ПДС может быть оценена по следующей формуле:Vmax - максимальная производительность информационного коммутатора по приему сообщений,байт/с. Так, для объема хранилища данных 1 Гбайт и максимальной скорости приема сообщений 2 Мбайт/с, продолжительность ПДС будет составлять не более 25 мин. В заключение перечислены основные преимущества, обеспечиваемые настоящим изобретением. При взаимодействии согласно настоящему изобретению приложения изолированы посредством соответствующих им ИК-стеков от сетевых протоколов и вызовов функций операционной системы, так как они взаимодействуют только с верхним уровнем (ADD) ИК-стека.- 28006307 Каждое из приложений, вне зависимости от того, передает ли оно или получает ПИОС, является инициатором информационного обмена с сетью информационной коммутации. Исходя из этого, всегда может быть реализована простейшая схема синхронизации приема данных (см., например, фиг. 10) и обработки данных, выполняемых приложением. Приложение-получатель является инициатором приема данных и выполняет его в "удобный" для себя момент времени. При этом имеется в виду, что приложению не требуется организовывать сложной обработки событий типа "прерывание" и связанной с ними промежуточной буферизации и синхронизации на уровне приложения. После передачи приложением-отправителем ПИОС в сеть информационной коммутации, сеть информационной коммутации выполняет буферизацию ПИОС. В случае недоставки ПИОС при блокируемом режиме передачи хотя бы одному из множества приложений-получателей, сеть информационной коммутации известит приложение-отправитель о таком нарушении. Таким образом, приложениеотправитель освобождается от функций контроля доставки данных до каждого приложения-получателя. Приложение-получатель, запрашивая ПИОС у своего локального информационного коммутатора,получит данные только в том случае, если этот информационный коммутатор содержит все ПИОС, реализующие соответствующую приложению-получателю информационную связь. При отсутствии полной реализации информационной связи (всего назначенного приложению комплекта ПИОС), информационный коммутатор известит приложение-получателя о неготовности данных. Этим достигается освобождение приложения-получателя от функций контроля комплектности данных, принимаемых от разных отправителей. Если представить, что приложение S1 выполняет только функцию ввода данных в информационную систему (фиг. 8), приложения S2 - функции обработки и сохранения, а S3 - только функцию вывода, то становится очевидным, что приложения S1, S2 и S3 можно интерпретировать как удаленные процессы единого приложения, осуществляющего ввод, обработку, сохранение и транзитный вывод данных. Следовательно, сеть информационной коммутации может быть использована как средство упрощения создания единого приложения, обеспечивающее возможность взаимодействия его процессов, выполняющих элементарные функции. После получения ПИОС от приложения-отправителя, сеть информационной коммутации контролирует актуальность (действительность) полученного ПИОС, сравнивая время его нахождения в сети информационной коммутации с предопределенным предельным значением - временем актуальности ПИОС. При превышении времени актуальности ПИОС сеть информационной коммутации уничтожает ПИОС. В случае блокируемого режима передачи, приложение-отправитель будет извещено об уничтожении ПИОС в результате превышения времени актуальности ПИОС. Значение времени нахождения ПИОС в сети информационной коммутации контролируется с помощью настройки информационных коммутаторов из состава сети информационной коммутации и определяется отдельно для каждой информационной связи в сети информационной коммутации. Приложения не могут влиять и не зависят от значения времени нахождения ПИОС в сети информационной коммутации. Упрощение создания и интеграции уже созданных программных приложений может быть обеспечено системой интеграции приложений за счет следующих дополнительно реализуемых возможностей: 1) Приложение может быть освобождено от преобразования формата данных, принимаемых от другого приложения, поскольку эта обязанность может быть возложена на сеть информационной коммутации или соответствующий ИК-стек. При несовпадении форматов данных уже существующих приложений, интегрируемых в единую информационную систему, ИК-стек может брать на себя прямое и обратное конвертирование форматов данных разнородных приложений (фиг. 11). 2) Приложение может быть разделено на несколько независимых элементарных процессов, синхронизация которых в рамках единого приложения может быть переложена на сеть информационной коммутации, как описано это выше. 3) Решение об изменении регламента (добавление или удаление отправителя или получателя, либо изменение времени нахождения ПИОС в сети информационной коммутации) информационной связи приложения может приниматься информационными коммутаторами автоматически, на основании анализа качества выполнения существующего регламента. На базе сети информационной коммутации может быть реализована функция контроля регламента (порядка следования ПИОС, интенсивности информационного обмена между приложениями, длин буферов сообщений, активности отправителей и получателей), что позволит изменять информационные связи при невыполнении требований регламента с целью обеспечения его выполнения. Сетью информационной коммутации обеспечивается гибкость за счет следующих возможностей: 1. Информационные связи между приложениями в сети информационной коммутации могут быть переопределены без вмешательства в исходный код приложений. Например, согласно фиг. 8 информационные связи между приложениями S1, S2 и S3 могут быть переопределены без изменения приложений таким образом, что приложение S3 будет выполнять транзитную функцию не для вводимых приложением S1 данных, а для данных, поступающих от другого приложения. При этом в ГТК в СУ ИК и в ЛТК ИК 1 будет удалена связь приложений (S1;P1) - (S3;P1) и введена новая связь (Sx;Py) - (S3;P1), где (Sx;Py) - адресная пара приложения, от которого будут поступать данные.- 29006307 Аналогичным образом приложению-отправителю S1 может быть добавлено еще одно приложениеполучатель, входящее, например, в состав системы безопасности предприятия. 2. Приложение, при соответствующем организационном обеспечении, может быть перенесено на любой компьютер сети при минимальных технических затратах. Так, в примере согласно фиг. 8, приложение S3, не подвергаясь изменениям, может быть перенесено с компьютера 2 на компьютер 4. При этом претерпит соответствующие изменения ГТК в СУ ИК, что повлечет автоматическое изменение ЛТК ИK1 и ИК 2. 3. Возможна реализация системы интеграции, в которой все изменения системного проекта могут производиться "на ходу" (runtime). Согласно настоящему изобретению упрощение создания и интеграции уже созданных программных приложений обеспечивается с помощью системы интеграции приложений за счет следующих возможностей: приложению для интеграции его в систему необходимо только объявить себя, свой ПИО-порт и режим блокируемости при передаче. Приложению не нужно знать списка адресов всех получателей передаваемого сообщения и, следовательно, не нужно принимать дополнительных мер при изменении такого списка; приложению не нужно знать такие детали, как сетевой протокол, особенности операционной системы и активность в данный момент приложения, с которым осуществляется взаимодействие, так как эти функции берет на себя сеть информационной коммутации; приложение всегда является инициатором передачи и приема данных, что освобождает его от необходимости синхронизации с другим приложением при передаче данных; приложение-отправитель может не заботиться о сохранности передаваемых данных и факте их доставки до получателя, для этого предусмотрена буферизация в сети информационной коммутации и средства контроля за адресной доставкой; приложению-получателю не нужно заботиться о комплектности принимаемых от разных отправителей данных, предназначенных для обработки. Для этого предусмотрена буферизация и контроль комплектности данных в информационных коммутаторах; приложение упрощается вплоть до одной автоматизированной функции обработки данных, таким образом снижаются затраты на разработку. Требуемая функциональность может быть получена путем настройки информационного обмена между такими атомарными приложениями; приложению не нужно производить контроль актуальности (своевременности доставки) данных,участвующих в обмене, так как эту функцию берет на себя сеть информационной коммутации, контролируя допустимое время нахождения ПИОС в этой сети. Изменения, связанные с удалением или добавлением информационных связей и добавлением приложений (примеры таких изменений приведены выше) могут производиться без остановки выполнения интегрированных приложений. При этом, в СУ ИК новая ГТК подготавливается и преобразовывается в локальные таблицы коммутации, которые затем загружаются в соответствующие информационные коммутаторы. После чего, происходит перезапуск всех информационных коммутаторов, задействованных изменениями, с использованием новых ЛТК. Масштабируемость информационной системы обеспечивается с помощью сети информационной коммутации за счет следующих возможностей: 1. В любой момент могут быть добавлены новые приложения и подсистемы, состоящие из приложений, без вмешательства в существующую структуру приложений. Добавление подсистемы, содержащей несколько приложений, производится аналогично добавлению отдельного приложения (фиг. 12). При этом в информационной системе выделяются все объединяющие информационные связи, необходимые для подключения подсистемы, и добавляются СУ ИК в хранящуюся в ней ГТК. После запуска информационных коммутаторов с новыми ЛТК, подсистема, содержащая несколько приложений, будет функционировать в составе единой новой информационной системы. 2. Созданные системы могут быть интегрированы в "надсистему" с другими системами (при реорганизации или слиянии компаний). Интегрирование систем в надсистему производится аналогично добавлению подсистемы в систему(фиг. 13), за исключением того, что перед формированием новой глобальной таблицы коммутации должны быть выделены объединяющие информационные связи в обеих интегрируемых системах. 3. Транзитная и вычислительная мощность корпоративной системы может быть увеличена добавлением информационных коммутаторов и разделением информационных потоков посредством информационных коммутаторов. Перенесение существующих приложений на другие компьютеры, подключенные в сеть предприятия, позволяет увеличить вычислительную мощность созданной информационной системы за счет увеличения объема доступных вычислительных ресурсов (фиг. 8).

МПК / Метки

МПК: H04L 12/58

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

Код ссылки

<a href="https://eas.patents.su/30-6307-sistema-sposoby-i-ustrojjstva-prednaznachennye-dlya-integracii-raspredelennyh-prilozhenijj.html" rel="bookmark" title="База патентов Евразийского Союза">Система, способы и устройства, предназначенные для интеграции распределенных приложений</a>

Похожие патенты

Игровая система, соответствующие способы и устройства для ее осуществления

Номер патента: 2456

Опубликовано: 25.04.2002

Автор: Штадельманн Антон Никлаус

МПК: A63F 3/08, G07F 17/32

Метки: игровая, система, устройства, способы, соответствующие, осуществления

Формула / Реферат:

1. Игровая система, в которой множество участников передают игровые данные участника по коммуникационной сети, по меньшей мере, в один игровой центр (3) для участия, по меньшей мере, в одной игре (31, 32, 33), а игровой центр (3) в соответствии с заранее определенными правилами игры проводит игры (31, 32, 33) и передает упомянутым участникам игровые данные игрового центра, причем игровые данные, которыми обмениваются участники игры и игровой...

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

Номер патента: 2930

Опубликовано: 31.10.2002

Авторы: Деккер Мартейн Й., Ван Ден Бринк Хендрикус Б.

МПК: G11B 7/00

Метки: носителя, использования, записи, оптической, носители, устройства, них, информационном, способы, слое, меток

Формула / Реферат:

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

Устройства для доставки лекарств с пролонгированным высвобождением, способы применения и способы их изготовления

Номер патента: 4980

Опубликовано: 28.10.2004

Авторы: Эштон Пол, Гуо Хонг

МПК: A61K 9/00

Метки: высвобождением, пролонгированным, устройства, доставки, применения, способы, лекарств, изготовления

Формула / Реферат:

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

Устройства и способы для пастеризации яиц в скорлупе

Номер патента: 1954

Опубликовано: 22.10.2001

Автор: Полстер Луис С.

МПК: B65D 85/32, A23L 1/32

Метки: скорлупе, устройства, пастеризации, способы, яиц

Формула / Реферат:

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

Устройства для диспергирования сухого порошка и способы их применения

Номер патента: 2869

Опубликовано: 31.10.2002

Авторы: Смит Адриан Е., Бурр Джон Д., Аксфорд Джордж С., Рэй Чарлз, Хол Рэнди К., Шнайдер Герм, Шулер Карлос

МПК: A61M 15/00

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

Формула / Реферат:

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

Предыдущий патент: Способ оценки степени тяжести и прогноза течения острого панкреатита

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

Случайный патент: Электронное устройство выбора позиции кодового диска

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

Формула / Реферат

Текст

МПК / Метки

Код ссылки

О сайте

Архивы

Контакты