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

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

 

Область техники

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

Предшествующий уровень техники

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

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

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

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

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

Наконец системы организации очередей сообщений обычно обеспечивают семантику только однократной доставки. В отличие от датаграммных, TCP и RPC моделей, очереди налагают условие буферизации между двумя поддерживающими связь сторонами, учитывая дополнительную связность и планирование гибкости. Многие системы организации очередей сообщений обеспечивают длительное сохранение состояния, предоставляя дополнительную доступность, допуская отказы в обработке и системные отказы. Некоторые системы организации очередей также имеют поддержку транзакций; эта модель может увеличивать надежность и доступность, автоматически отменяя частичную работу и допуская автоматическую повторную обработку. Эти системы обычно налагают ограниченные возможности хранения, такие как требования использования частного, длительного хранения, и имеют транспортные зависимости, которые ограничивают конфигурацию сети.

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

Сущность изобретения

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

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

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

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

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

Краткое описание чертежей

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

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

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

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

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

Подробное описание предпочтительных вариантов осуществления

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

Фиг.1 иллюстрирует укрупненное представление стеков 100а и 100b для надежной передачи сообщений. В стеке передачи сообщений без надежного протокола 125 передачи сообщений (Reliable Messaging Stack) приложение 105, при наличии необходимости передать сообщение, например, на другой уровень 185 приложения, передало бы сообщение или серию сообщений 115 непосредственно к уровню 140 датаграмм передачи сообщений. (Следует заметить, что приложение 105 может относиться к любому типу приложений, например, быть услугой и в общем случае должно рассматриваться как охватывающее соответствующую систему (структуру) приложений в качестве подходящей.) Поскольку датаграммы не надежны, сообщения или сообщение 115, могут быть продублированы, отсрочены и/или пропущены. Например, в менее надежном протоколе передачи датаграмм, имеющем надежность типа "послал и забыл", сообщение или сообщения 115 могут быть пропущены по любой причине, включая причины, связанные с посредником 135 между средствами 160 и 165 транспортировки. Соответственно, приложение 185 в оконечной точке партнера может никогда не получить сообщение или сообщения 115, и посылающее приложение 105 не узнает, что сообщение или сообщения 115 не были приняты.

В соответствии с примерами вариантов осуществления настоящего изобретения, однако, стеки 100а и 100b надежной передачи сообщений снабжаются протоколом 125 надежной передачи сообщений. Соответственно, например, система (структура) 120 (или альтернативно 180) надежной передачи сообщений может гарантировать, что сообщение или сообщения 115, посланные из приложения 105 должным образом достигли их адресата в оконечной точке. Например, если приложение 105 желает передать сообщение или сообщения 115 к приложению 185 - его партнеру в сеансе связи, приложение 105 может послать сообщение или сообщения 115 Send() к системе 120 надежной передачи сообщений, где им назначают сеанс связи и заданные порядковые номера сообщения. Идентификатор сеанса связи соответствует сеансу связи между приложением 105 и приложением 185. Другими словами, сеанс относится к дуплексному сеансу связи между этими двумя прикладными программами 105 и 185. Нумерация в последовательности соответствует конкретному сообщению в рамках связи сеанса. Например, могут существовать несколько сообщений в рамках одиночного сеанса, имеющего место между этими двумя прикладными программами 105 и 185, и каждое сообщение пронумеровано последовательно в порядке, посланном приложением. Кроме того, могут существовать многократные сеансы, устанавливаемые между прикладными программами 105, 185 и, возможно, другими прикладными программами (каждый установленный сеанс может иметь одни и те же или различные гарантии доставки). Соответственно, каждому сообщению может быть назначены сеанс и порядковый номер, уникально идентифицирующий конкретный сеанс и порядковый номер в последовательности передачи сообщений в рамках сеанса.

После записи сеанса и заголовка последовательности относительно сообщения 191 и выполнении другой требуемой канальной обработки сообщение 191 сохраняют в Состоянии 190 Сеанса (Session State) в буфере передачи. Затем копия сообщения 191 передается вниз через уровень 140 передачи датаграммных сообщений, который облегчает сквозную передачу сообщения 191, например, обеспечивая маршрутизацию заголовков. Сообщение 191 затем передается, возможно, через один или более посредников, например Посредник 135, каждый из которых облегчает сквозную передачу сообщения 191 в конечные точки передачи. Может использоваться расширяемый механизм перехвата, чтобы осуществить различные типы поведения, такие как маршрутизация, фильтрация, управление политикой и защита. Следует отметить, что механизмы (средства) 145, 170, 155 транспортировки и типы поведения, доступные в конечных пунктах в оконечных точках передачи сообщений и посреднике 140, 175, 150, могут быть установлены или программным путем, или посредством настройки конфигурации.

Если для приложения 105 указана (задана) гарантия по-меньшей-мере-однократной-доставки (описанная более подробно ниже), система (структура) 120 надежной передачи сообщений ожидает прием подтверждения от системы (структуры) 180 надежной передачи сообщений, указывающей, какие сообщения приняты должным образом. Сообщение 192 несет подтверждение, что сообщение 191 (например, сообщение 5 в последовательности) было принято. Периодически, если сообщение 192 подтверждения не принято системой 120 надежной передачи сообщений, или из-за того, что копия должным образом не была принята системой (структурой) 180 надежной передачи сообщений, или из-за того, что ни одно из подтверждений от 180 не были приняты в 120, сообщение 191 передают снова. Соответственно, если сообщение 191 было пропущено, задержано или неверно маршрутизовано, например, Посредником 135, система 120 надежной передачи сообщений продолжает (в течение периода блокировки по времени, описанного ниже) периодически передавать сообщение 191 в попытке гарантировать, что по меньшей мере одна копия сообщения 191 должным образом принята системой 180 надежной передачи сообщений. Следует отметить, однако, что по подобным причинам, как описано выше в отношении сообщения 191, подтверждение 192 может быть пропущено, задержано или неверно маршрутизовано. Как таковое, настоящее изобретение обеспечивает надежную доставку сообщения для сообщения 192 подтверждения, как описано ниже.

Как только система (структура) 180 надежной передачи сообщений успешно принимает копию сообщения 191, она посылает сообщение 192 подтверждения системе 120 надежной передачи сообщений. После получения сообщения 192 подтверждения система 120 надежной передачи сообщений удаляет из ее буфера 190 (посылки) состояния сеанса связи копию сообщения 191 и останавливает выполнение дополнительных его передач. Аналогично система 180 надежной передачи сообщений записывает в свое состояние 195 сеанса связи, что она получила копию сообщения 191, для того, чтобы любые дублирующие сообщения, принимаемые системой 180 надежной передачи сообщений, могли быть отвергнуты независимо от того, действительно ли сообщения уже доставлены приложению 185. Затем приложение 185 может извлекать из буфера 195 состояния (приема) сеанса связи принятое сообщение посредством своей команды Receive() (принять). Если система 120 надежной передачи сообщений не принимает подтверждение из-за его потери, задержки или неправильной маршрутизации, то повторная передача сообщения 191 продолжится, таким образом вынуждая систему 180 надежной передачи сообщений посылать другую копию подтверждения 192. Этот процесс может продолжаться до тех пор, пока, по меньшей мере, одно подтверждение 192 не будет принято системой 120 надежной передачи сообщений или пока система 120 надежной передачи сообщений не откажется повторять и посылать индикацию об ошибке к приложению 105.

Системы (структуры) 120 и/или 180 надежной передачи сообщений могут быть каждая выполнены с возможностью проведения Диалога 200 (фиг.2) в соответствии с настоящим изобретением и как более подробно описано со ссылками на Фиг.2. Диалог 200 является абстракцией структуры (системы передачи) сообщений, в которой службы (или экземпляры прикладных программ) используют Диалог 200 для надежной ориентированной на сеанс связи с другими службами. Программисты могут использовать Канал 220 Диалога для доступа к Диалогам. Кроме того, Диалог 200 обеспечивает инфраструктуру надежной передачи сообщений и единую программную модель, когда гарантии доставки сообщения к прикладным программам являются настраиваемыми. Эти гарантии надежности должны быть удовлетворены или происходит отказ в осуществлении сеанса связи. Конструкция Диалога 200 предоставляет соответствующей реализации во время выполнения гибкость для того, чтобы предложить дополнительные возможности (свойства), подчиненные поддержанию гарантий (ограничений корректности), установленных для реализации прикладной задачи. В частности, приложение может быть обеспечено различной степенью доступности и масштабируемости, прозрачной для реализации прикладной задачи. Кроме того, этот обмен сообщениями во время сеанса связи между приложениями 105 и 185 может быть реализован посредством ряда типов механизмов транспортировки (например, TCP/IP 160 и HTTP (гипертекстовый транспортный протокол) 165), экземпляров транспортных соединений и топологии сети.

Гарантии надежности, обеспечиваемые Диалогом 200, включают в себя по-меньшей-мере-однократную (ALO, ПМО), самое-большее-однократную (АМО, СБО) и упорядоченную (10, УД) доставку. Также предоставляется дополнительная гарантия "время действительности сеанса" (TTL, ВДС). Гарантия СБО гарантирует, что для любого заданного сообщения, посланного посылающим приложением, сообщение будет доставлено принимающему приложению самое большее однократно. Поскольку Диалог 200 является абстракцией, приложение освобождается от необходимости обнаруживать и отклонять дублирующие сообщения, если дублирующие сообщения будут нарушать семантику приложения. Аналогично гарантия ПМО обеспечивает, что все сообщения, посланные посылающим приложением, приняты принимающей оконечной точкой, что освобождает приложения от необходимости обнаружить потерянные или неверно направленные сообщения и координировать их повторную передачу. Гарантия УД обеспечивает то, что сообщения доставляются принимающему приложению в порядке, в котором они были посланы посылающим приложением. Это освобождает приложение от необходимости иметь дело с нарушенным порядком приема сообщений.

Диалог 200 также предоставляет сеансу связи гарантию ВДС, которая требует, чтобы сеанс диалога между партнером и оконечной точкой партнера был завершен до истечения ВДС сеанса связи. Если ВДС сеанса связи истекает до завершения сеанса диалога, каналы диалога устанавливаются в состояние "сбой", и приложениям выдается уведомление об ошибке. Приложения могут продлевать ВДС сеанса связи, повторно осуществляя согласование ВДС.

Диалоги позволяют использовать эти гарантии доставки сообщения или по отдельности, или в любой комбинации для выполнения конкретных требований данного приложения и развертывания. Например, комбинация трех гарантий ПМО, СБО и УД обеспечивает только однократную упорядоченную доставку для наиболее надежных механизмов обмена, типа TCP/IP. В отличие от типовых механизмов связи и их соответствующих программных моделей, однако, эти гарантии могут быть настроены без изменения модели программирования, которые эти приложения используют.

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

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

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

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

В соответствии с еще одним вариантом осуществления Хранилища Диалога (например, Хранилище 260 Диалога) информация о состоянии сеанса связи поддерживается в течение длительного времени в базе данных, таком как сервер языка структурированных запросов (SQL). Это длительное состояние может сохраниться при отказе компьютерного узла или операционной системы, однако, за счет выполнения записей на диск, чтобы поддерживать состояние. Одним из преимуществ использования системы базы данных типа SQL-сервера для поддержания состояние является то, что инсталляции могут уже иметь инструментальные средства, способы и процессы вместо выполнения регулярного дублирования и восстановления состояния важного приложения.

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

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

Другим настраиваемым свойством, предлагаемым Диалогом 200, является буферная квота. Диалог 200 буферизует сообщения в отправляющем и принимающем приложениях. Эта буферизация увеличивает автономность этих двух приложений, позволяя стороне или посылать, или принимать сообщения к или из их локальных буферов, даже если другая сторона не выполняется (не работает) или недостижима, например, из-за разделения сети. Например, может продолжать посылать сообщения даже при том, что другая сторона временно недоступна, то есть не выполняется или недостижима. Это выполняется посредством накопления сообщений в локальном буфере 250 посылок (Send Buffer) до тех пор, пока они не смогут быть успешно переданы. Аналогично приложение 205 может принимать сообщения, которые были предварительно буферизированы в буфере 245 приема (Receive Buffer), даже при том, что приложение, которое послало их, в настоящее время может не выполняться. Диалог 200 обеспечивает настраиваемую буферную квоту, которая определяет максимальное число сообщений (квота на размер сообщения), которые будут буферизированы системой. Соответственно, это ограничивает объем пространства, используемого Состоянием 235 Диалога (Dialog State), и ограничивает локальные ресурсы, которые могут быть использованы другой оконечной точкой. Это также позволяет системе передачи сообщений резервировать пространство (область памяти), достаточное для приложения, чтобы локально буферизовать указанное количество сообщений. Диалог 200 также предусматривает минимальную буферную квоту, которая определяет минимально зарезервированное число сообщений, которые буферизируются инфраструктурой передачи сообщений, которая в комбинации с максимальным размером сообщения определяет минимальное число байтов, которые будут буферизированы инфраструктурой передачи сообщений. Буферная квота может быть настроена посредством профиля (как описано ниже) или определена в коде приложения.

Диалог 200 также обеспечивает настраиваемое свойство блокировки по времени при посылке. Когда сообщение послано, оно помещается в Хранилище 260 Диалога/буфер 250 посылки. Если буфер полон, то есть, если достигнута буферная квота, то запрос к Send() 210 блокируется до тех пор, пока не истечет блокировка по времени при посылке, или в буфере не станет доступным пространство (область) для сохранения сообщения. Область становится доступной в буфере, когда сообщения успешно переданы и подтверждены получающей оконечной точкой, и больше отсутствует необходимость повторения для локальной оконечной точки. Если область становится доступной прежде, чем истечет блокировка по времени при посылке, запросы Send() 210 завершаются обычным образом. Если блокировка по времени при посылке истекает прежде, чем область становится доступной, возникает исключительная ситуация, обеспечивая уведомление приложению о том, что сообщение не может быть успешно буферизировано (захвачено). Соответственно, приложение может попытаться выполнить позже эту операцию. Настраиваемая блокировка по времени позволяет приложениям выбирать степень ответственности на основании простоты блокирования. Блокировка по времени при посылке может быть настроена посредством профиля (как описано ниже) или определена в коде приложения.

Как упомянуто выше, Диалог 200 поддерживает гарантию ВДС для сквозного сеанса связи. Диалог 200 также обеспечивает необязательное сообщение "Время Действительности Сеанса", которое является настраиваемым в качестве локального свойства. Сообщение ВДС требует, что передаваемое сообщение должно быть успешно принято принимающей оконечной точкой в течение времени, указанного в ВДС, иначе приложению 205 передается ошибка. Диалог 200 также обеспечивает настраиваемое продление для сообщения ВДС. Соответственно, когда ВДС истекает, к передающему приложению 205 передается уведомление. Приложение 205 затем имеет выбор: завершить диалог или продлить ВДС сообщения. Аналогично блокировкам по времени при посылке ВДС может быть установлено кодом приложения или настроено косвенно с использованием профиля.

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

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

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

В соответствии с примерными вариантами осуществления и как описано ниже со ссылкой на Фиг.2, в оконечной точке отправителя, когда вызывают Send() 210, сообщение условно помещают в Хранилище 260 Диалога. Если совершается транзакция, сообщение передается Хранилищу 260 и делается доступным для передачи к оконечной точке партнера. Если транзакция завершается аварийно, сообщение отвергается. В приемнике, когда вызывают Receive() 215 (или Delete (Удалить)), сообщение условно удаляют из Хранилища 260 Диалога. Если транзакция совершается, сообщение постоянно удаляется из Хранилища 260. Если транзакция завершается аварийно, сообщение остается в Хранилище 260 и доступно для повторной доставки. Транзактный прием учитывает только однократную-обработку-сообщений.

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

Другим свойством, обеспеченным Диалогом 200, является необязательная функция сообщения-"отравителя". Как упомянуто выше, когда сообщение принято и обработано как транзакция и когда транзакция завершается аварийно, сообщение остается в Хранилище 260 Диалога и доступно для повторной доставки к приложению. Иногда проблема, которая заставляет транзакцию прерываться, является недолговечной, например, блокировка по времени из-за взаимоблокировки, и доставка, и обработка сообщения успешно выполняются при следующей попытке. Если попытки доставки для заданного сообщения неоднократно вызывают аварийное прекращение работы, сообщение рассматривается как "отравитель". Диалог 200 обеспечивает способ настройки количества раз, сколько аварийных прекращений работы при доставке сообщения должны быть выполнены прежде, чем сообщение рассматривается как "отравитель". Когда сообщение-"отравитель" обнаружено, приложению передается сообщение об ошибке, и дополнительные попытки обработки сообщения приостанавливаются до тех пор, пока приложение не выполнит корректирующее действие. Это гарантирует, что ресурсы обработки не будут потрачены впустую, делая попытку выполнить работу, которая никогда не может быть успешной или может быть успешной только после некоторого вмешательства. Обнаружение сообщения-"отравителя" может быть настроено посредством профиля (как описано ниже) или определено в коде приложения.

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

Поскольку Диалог 200 предусматривает любую комбинацию этих возможностей (свойств) и гарантий независимо от друг друга, Диалог 200 может быть сконфигурирован так, чтобы удовлетворить любую конфигурацию соединения из моделей программирования с сильной связью, таким как Протокол Управления Передачей (TCP) и Удаленный Вызов Процедур (RPC), моделей программирования с гибкой связью, аналогичным датаграммам и очередям. Кроме того, Диалог 200 эффективно поддерживает различные модели двустороннего обмена сообщениями (МЕР, МДОС), такие как одностороннее, полудуплексное (от одиночного запроса/ответа до более сложных моделей) и наиболее сложные - дуплексные взаимодействия. Соответственно, Диалог 200 учитывает унификацию программной модели двусторонней связи.

Фиг.2 иллюстрирует операционные особенности Диалога 200 в соответствии с примерными вариантами осуществления настоящего изобретения. Программный интерфейс приложения (API) 220 Канала Диалога (Dialog Channel) обеспечивается в качестве абстракции для приложения 205. Как описано выше, Диалог 200 использует протокол передачи сообщений, такой как WEB-Служба Надежной Передачи сообщений (WS-RM), который определяет последовательность сообщений. Последовательность определяет набор однонаправленных сообщений во время сеанса. Две такие последовательности объединяются для формирования диалога, одна последовательность в каждом направлении между двумя сторонами, поддерживающими связь. Когда вызывается метод Send() (послать) 210 Канала 220, сообщение, которое передается как параметр в метод Send 210, сохраняют в Состоянии 250 Посылки (State Send) и уникально отмечают временной меткой с монотонно увеличивающимся порядковым номером сообщения в соответствии с порядком, в котором это сообщение было послано.

Сообщения 255 буферизуют в Состоянии 250 Посылки, чтобы поддерживать состояние отдельных сообщений 255 в последовательности. В этот момент можно сказать, что сообщения "захвачены" в Состоянии 250 (State), и метод Send() 210 осуществляет возврат к приложению. Более конкретно метод Send() 210 принимает одно сообщение в качестве параметра. Это сообщение, которое передают на буфер Send 250 (послать) для пометки временной меткой с порядковым номером и последующим или одновременным сохранением в хранилище Store 260. Именно в этот момент сообщение считают "зафиксированным" (захваченным), и метод Send() 210 завершается. Повторение этого запроса с другими сообщениями приводит к последовательности или частичной последовательности сообщений 255.

Состояние 235 Диалога (Dialog State) содержит буферы 250 и 240 посылки и приема (Send и Receive) соответственно. Состояние 235 Диалога управляет и сохраняет такую инвариантную информацию, как идентификатор Диалога, гарантии, заданные для приложений, и адрес оконечной точки партнера. Состояние 235 Диалога также управляет информацией сеанса, такой как следующий порядковый номер исходящей передачи и состояние подтверждения. Дополнительно данные конфигурации, такие как ВДС Диалога, блокировка по времени, расположение хранилищ и т.д., поддерживаются в Состоянии 235 Сеанса Диалога (Dialog Session State).

Как только сообщение зафиксировано (захвачено), Протокол (Protocol) 270 может обрабатывать и передавать захваченное сообщение, например сообщение 275, соответственно через Порт (Port) 285. Программная модель и инфраструктура во время выполнения для Диалога 200 обеспечивают гибкую и эффективную модель разрешения для оконечной точки. Модель, как минимум, обеспечивает, чтобы эти две оконечных точки были достаточно разрешены, чтобы обеспечить надежный обмен сообщения. В частности, Протокол 270 может страховать перед доставкой начального сообщения в диалоге для обработки, что обе оконечных точки поддерживают основу, достаточную для того, чтобы гарантировать уникальность оконечной точки и правильную корреляцию сообщений через Диалог 200 и его соответствующим сеансом связи. Это требуется, например, для того, чтобы гарантировать, что сообщение надежно поставляется единственному партнеру по сеансу, чтобы гарантировать самое-большее-однократную-доставку. Это разрешение оконечной точки может быть основано на множестве факторов, включая идентификатор, который идентифицирует приложение партнера (например, Универсальный Идентификатор Ресурса (URI)), используемый создателем Диалога 200, локальную конфигурацию, маршрутизацию данных в заголовках сообщения, конфигурации посредника и конфигурацию приложения-назначения.

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

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

Протокол 270 также определяет какой тип сквозной гарантии, и локальные свойства определены приложением 205, независимо от способа для выполнения разрешения оконечной точки, описанного выше. Если приложение 205 задает гарантию ПМО, Протокол 270 сохраняет копию сообщения 275 в буфере 250 посылок (Send Buffer) Диалога до тех пор, пока Протокол 270 не примет положительное подтверждение от получателя (не показано) о том, что сообщение 275 было должным образом принято. Когда Протокол 270 принимает положительное подтверждение от получателя, он делает запись этого факта в Состоянии 235 Сеанса и удаляет сообщение из буфера 250 посылок. Если Протокол 270 не принимает положительного подтверждения в течение заданного периода блокировки по времени для повторения, протокол повторно передает копию того же сообщения 275 с тем же самым порядковым номером сообщения. Диалог 200 может повторить этот процесс неоднократно и может использовать стратегии отсрочки повторения после истечения времени по таймеру, чтобы избежать дополнительной перегрузки в сети. Если подтверждение не принято в течение периода времени, заданного в соответствии с сообщением ВДС, то возникает ошибка, которую нужно передать посылающему приложению 205 о том, что гарантия не может быть удовлетворена.

Когда сообщение 280 диалога принято, протокол 270 копирует сообщение в состояние 240 буфера приема. Протокол 270 также записывает следующий ожидаемый порядковый номер сообщения. Когда сообщение 280 принято, если гарантии Диалога 200 включают в себя СБО, порядковый номер сообщения для поступающего сообщения 280 сравнивают с набором порядковых номеров сообщения, которые поступили ранее, которые, как упомянуто выше, сохранены в состоянии 240 буфера приема. Если набор уже содержит совпадающий порядковый номер, сообщение 280 рассматривается дублирующим и отвергается; иначе, сообщение 280 помещается в локальный буфер 240 приема для последующей ссылки.

Если гарантии включают в себя ПМО, то Протокол 270 посылает не относящееся к последовательности, завершенное выборочное положительное подтверждение о приеме сообщения 280 в оконечную точку партнера по диалогу. Это подтверждение должно включать в себя порядковые номера всех сообщений, которые были приняты к настоящему времени в течение сеанса. Краткое примечание, которое включает в себя набор диапазонов последовательности, может использоваться для сохранения объема сообщения. Если заданные гарантии не включают в себя УД, то сообщение 280 немедленно делается доступным для "доставки" к принимающему приложению 205 через Канал 220 приема (Receive Channel). В частности, приложению 205 посылают уведомление, что сообщение доступно для приема. Приложение 205 может затем вызывать Receive() 215, после чего следующее сообщение, доступное для доставки, передают к приложению 205, и можно считать, что "доставка" произошла.

Если задана гарантия УД, то порядковый номер поступающего сообщения 280 сравнивается со следующим ожидаемым порядковым номером. Если порядковый номер меньше, чем следующий ожидаемый порядковый номер, поступающее сообщение 280 отвергают. Если они совпадают, поступающее сообщение 280 немедленно делают доступным для доставки к принимающему приложению 205, и следующий ожидаемый порядковый номер устанавливают равным номеру следующего отсутствующего сообщения. Если порядковый номер больше, чем следующий ожидаемый порядковый номер, то поведение зависит от того, задана ли также гарантия ПМО. Если гарантия ПМО не задана, то сообщение 280 немедленно делают доступным для доставки к принимающему приложению 205, и следующий ожидаемый порядковый номер устанавливают равным на единицу больше, чем порядковый номер поступающего сообщения 280. Если задана гарантия ПМО, сообщение 280 не делается доступным для доставки к принимающему приложению 205, но остается в буфере 240 приема. Соответственно, если они не совпадают, предполагается, что по меньшей мере одно другое сообщение с меньшим порядковым номером еще не было принято. Когда все такие пропущенные с меньшим номером сообщения поступили, тогда непрерывная совокупность сообщений делается доступной для доставки к принимающему приложению в соответствующей последовательности, и следующий ожидаемый порядковый номер устанавливают равным отсутствующему номеру следующего сообщения.

Как упомянуто выше, когда сообщения доступны для доставки к принимающему приложению 205, уведомление выдают к принимающему приложению 205. Принимающее приложение может затем вызвать метод 215 Receive() по Каналу 220 Диалога, чтобы принять доставку следующего доступного сообщения. Receive() может быть вызван многократно, чтобы принять каждое доступное сообщение в свою очередь. Чтобы обеспечивать упорядочение, уведомления о событиях доставляют последовательно. Соответственно, когда сообщение доступно для доставки к приложению 205, одиночное уведомление о событии доставляют приложению 205 посредством вызова кода приложения, который был предварительно зарегистрирован с событием 200 Диалога. Пока этот запрос к коду приложения не возвратит результат, никакие другие запросы к этому прикладному коду не будут сделаны, даже если другие сообщения доступны для доставки. В пределах этого прикладного кода приложение 205 обычно будет вызывать Receive() 215 Диалога, чтобы принять следующее доступное сообщение.

Как также описано выше, когда вызывается Send() 210, число сообщений, находящихся в это время в буфере 250 посылки (Send Buffer), сравнивается с заданной буферной квотой. Если оно превышает квоту, вызывающая программа Send() 210 блокируется на событии, или пока область не станет доступной, или пока блокировка по времени при посылке не будет превышена. Когда область становится доступной в буфере 250 посылки, буфер проверяет, имеются ли какие-либо вызывающие программы, ожидающие посылки сообщения. Если есть, то вызывающий метод Send() 210 разблокируется и снова может посылать сообщения.

Все состояния для Диалога 200, включая те, что находятся в буферах 250 и 240 сообщений, в Канале 220 и в Протоколе 270 могут одновременно поддерживаться в Хранилище 260 Диалога (Dialog Store). Хранилище 260 Диалога должно содержать наиболее позднюю по времени обновления информацию. Это гарантирует, что Состояние 235 Диалога (Dialog State) обладает свойствами долговечности Хранилища 260 Диалога и позволяет всем особенностям (свойствам) функционировать независимо от Хранилища 260, которое находится в использовании. Например, помещая сообщение 280 в буфер 240 приема, можно включать записи на диске в Хранилище 260. Чтобы обеспечивать гарантии, подтверждения посылают только после того, как сообщение было записано в Хранилище 260. Это обеспечивает, например, что или отправитель, или получатель всегда имеет копию сообщения. Аналогично на стороне посылки Send() 210 может завершиться только после того, как сообщение было записано в Хранилище 260.

Как упомянуто выше, Хранилищем 260 Диалога может быть подключаемое хранилище, обеспечивая огромную гибкость для удовлетворения требованиям долговечности, эффективности, автономности и административным целям. Например, Хранилище 260 может быть выбрано из одного множества хранилищ в пределах одной структуры, включающей в себя следующее: реализацию Хранилища Диалога в оперативной памяти, которое сохраняет все состояние в памяти приложения; специальную реализацию Хранилища Диалога, которая хранит состояние в памяти отдельного выделенного фонового процесса; или реализацию хранилища базы данных длительного хранения, такую как сервер языка структурированных запросов (SQL). Различные диалоги в пределах одного и того же приложения 205 могут использовать различные хранилища. Кроме того, настоящее изобретение также обеспечивает, что некоторые Хранилища 260 Диалога могут быть сконфигурированы для выполнения на локальном компьютерном узле или другом узле.

Поскольку Диалог 200 действует как агент от имени приложения 205, приложение 205 изолировано от изменений в связности. Это допускает, например, пакетные стили обработки, когда приложение запускается, посылает и принимает некоторые сообщения и затем завершается без необходимости ожидания другой оконечной точки для ответа или даже точки, когда оно должно быть доступным. Далее доставка сообщения может быть запланирована с большой гибкостью, должна только удовлетворять различным гарантиям доставки и локальным особенностям (свойствам), например ВДС сообщения или сеанса. Например, подчиненный гарантиям доставки Диалог 200 может растягивать пиковые загрузки сообщений по некоторому периоду времени (балансировка загрузки) или иным образом сдвигать доставку сообщения на более эффективное по стоимости время, ждать, когда ресурс станет доступным, учитывать приоритет сообщения или Диалога и т.д. независимо от приложения 205. Кроме того, Хранилище 260 обеспечивает возможности завершения и повторного запуска приложения 205. Пакетная обработка, планирование, а также возможности завершения приложения и повторного запуска увеличивают доступность и масштабируемость системы.

Кроме того, как упомянуто выше, приложение 205 может указать, чтобы операции Send() 210 или Receive() 215 были транзактными по отношению к буферам 250 и 240 Диалога. Это позволяет приложению, например, принимать сообщение, посылать некоторые сообщения в одном или более диалогов и обновлять таблицу приложений - все в течение одной транзакции. В таком использовании транзакций это является просто локальным понятием и не переносится к другой оконечной точке.

Диалог также обеспечивает возможность восстановления при сбое во время выполнения, при которой может быть автоматически восстановлено (маскировано) множество ошибок 265 без вызова реализации приложения. Приложение может полагаться на прием установленных характеристик (то есть установленной гарантии и свойств) для работы Диалога 200. Если инфраструктура для Диалога 200 или Протокола 270 определяет, что установленные характеристики больше не могут быть удовлетворены, диалог переводится в состояние "сбой", и возникает событие ошибки, позволяя осуществить дополнительное корректирующее действие, независимое от основного кода приложения или даже приложения 205. Если ошибка (сбой) 265 может быть исправлена (состояние восстановлено), диалог может быть помещен обратно в обслуживание. Неисправимые отказы, то есть ошибки, которые не могут быть восстановлены, могут приводить к завершению Диалога 200 и уведомлению приложения. Такая схема соответствует модели "сбой - быстрое восстановление", которая является фундаментальной для развития надежных приложений.

Отказы в живучести могут включать в себя следующие:

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

Диалог 200 может автоматически пытаться восстанавливать эти ошибки на свое усмотрение, например, снова посылая сообщение. Альтернативно или в дополнение Диалог 200 может посылать запрос третьей стороне, например системному оператору или диагностической программе, запрашивая помощь для восстановления ошибки. Этой помощью может быть, например, простое вмешательство человека, чтобы восстановить нарушенное подключение в сети, или, возможно, автоматизированный процесс ремонта. В любом случае, как только ошибка восстановлена, Диалог 200 может продолжать посылать сообщения. Это, вместе с другими свойствами доступности, обеспечивает долговечные Диалоги. Если, однако, ошибка не может быть разрешена Диалогом 200 или посредством вмешательства некоторого другого третьего лица, сообщение об ошибках должно быть передано к приложению 205, которое инициализировало диалог.

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

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

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

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

Фиг.3 иллюстрирует "цикл жизни" и состояния Диалога 200. Диалог 200 может быть в одном из двух главных состояний - Активное 320 или Неактивное 360. Если Диалог 200 Активен 320, то объект 220 канал диалога (Dialog Channel) находится в памяти, иначе, если Диалог 200 Неактивен 360, Диалог 200 существует только в Хранилище 260 Диалога. Управление системными ресурсами происходит через Деактивизацию 350 и Реактивизацию 340 процессов, которые могут происходить вручную или автоматически. Например, Деактивизация 350 может происходить вручную, если приложение вызывает Распределение (Dispose), или автоматически из-за времени неактивности, при котором истекает некоторый период времени, когда не осуществляется обмен сообщениями по каналу диалога. Такой канал может быть Деактивизирован (соответствующие объекты освобождают память), таким образом освобождая ресурсы памяти для других программ.

Реактивизация 340 может происходить вручную, если приложение запрашивает Канал от Администратора Диалога (Dialog Manager) (не показан), или Реактивизация 340 может происходить автоматически, если в сеансе приходит новое сообщение. Каждому диалогу Администратором Диалога назначается уникальный идентификатор ИД в течение Создания 310 Диалога. Этот идентификатор передается приложением 205 к Администратору Диалога по запросу Реактивизации 340, и Администратор Диалога использует идентификатор, чтобы определить состояние диалога и повторно инициализировать канал. Интерфейсы Деактивизация 350 и Реактивизация 340 позволяют системе ограничивать ресурсы обработки, связанные с Диалогами, которые активно не используются для посылки исходящих сообщений или обработки входящих сообщений. Это позволяет инфраструктуре востребовать соответствующие ресурсы кроме тех, что связаны с Хранилищем 260 Диалога. Кроме того, эта схема допускает планирование ресурсов, включая: планирование передачи сообщения на основании приоритета или доступности ресурса; пакетирование сообщений для более эффективной передачи; планирование доставки сообщения на основании приоритета или доступности ресурса; и пакетирование доставки сообщения для более эффективной обработки.

Операция "Создание" 310 Диалога управляется Администратором Диалога и может быть инициализировано приложением, которое вызывает функцию "Создание" 310. Альтернативно система передачи сообщений может инициализировать Создание 310 Диалога после принятия сообщения от другой оконечной точки, указывающей потребность в новом диалоге. В этом случае система уведомляет приложение 205, что требуется диалог. Приложение 205 может тогда вызывать метод Accept (принять) в Администраторе Диалога, чтобы принять запрос на диалог, и вызывать Создание 310 Диалога, или оно может вызвать метод Reject (Отклонить) в Администраторе Диалога, чтобы отклонить запрос диалога. Администратор Диалога также управляет демонтажем (Teardown) 330, который может быть инициализирован вследствие пары причин. Одной причиной может быть та, что сеанс завершился успешно, то есть обе стороны выполнили посылки сообщений и больше сообщений не осталось. Другая причина для демонтажа 330 может состоять в том, что Диалог 200 прерван, например приложение вызвало функцию Terminate() (Закончить), или от оконечной точки партнера принята индикация о завершении. Когда одна сторона завершает диалог, сообщение посылается другой стороне, чтобы указать на это. Не имеется никакой надежности для этого сообщения, это является просто попыткой сообщить другой стороне, что диалог был завершен. Завершение подразумевает, что никаких дальнейших обменов сообщений больше не будет в течение сеанса диалога.

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

Варианты осуществления в объеме настоящего изобретения также включают в себя считываемые компьютером носители для переноса или хранения выполняемых компьютером команд или структур данных, сохраненных на них. Такие считываемые компьютером носители могут быть любыми доступными средствами, к которым можно обращаться с помощью компьютера общего назначения или специализированного. Посредством примера, а не ограничения, такие считываемые компьютером носители могут содержать оперативную память (ОЗУ), постоянное запоминающее устройство (ПЗУ, ROM), электрически стираемое перепрограммируемое ПЗУ (ЭСППЗУ, EEPROM), CD-ROM или другое запоминающее устройство на оптическом диске, магнитную память на диске или другие магнитные запоминающие устройства, или любую другую среду, которая может использоваться для переноса или хранения требуемых программных кодов в форме выполняемых компьютером команд или структур данных и к которой можно обращаться с помощью компьютера общего назначения или специализированного компьютера. Когда информация передается или предоставляется по сети или другому соединению связи (или аппаратному, беспроводному, или комбинации аппаратных или беспроводного) на компьютер, компьютер должным образом рассматривает соединению как считываемую компьютером среду.Таким образом, любое такое соединение правильно называть считываемой компьютером средой. Комбинации вышеупомянутых средств должны также быть включены в рамки считываемых компьютером носителей. Выполняемые компьютером команды содержат, например, команды и данные, которые вынуждают универсальный компьютер, специализированный компьютер или специализированное устройство обработки исполнить некоторую функцию или группу функций.

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

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

Со ссылкой на Фиг.4 приведенная в качестве примера система для осуществления изобретения включает в себя универсальное вычислительное устройство в форме компьютера 420 общего назначения, включающего в себя процессор 421, системную память 422 и системную шину 423, которая соединяет различные системные компоненты, включая системную память 422 и процессор 421. Системная шина 423 может быть любой, из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, используя любую из ряда шинных архитектур. Системная память включает в себя постоянное запоминающее устройство (ПЗУ, ROM) 424 и оперативную память (ОЗУ, RAM) 425. Базовая система ввода/вывода (BIOS) 426, содержащая основные подпрограммы, которые помогают передавать информацию между элементами в компьютере 420, например, во время включения может быть сохранена в ROM 424.

Компьютер 420 может также включать в себя накопитель 427 на жестком диске для считывания с и записи на магнитный жесткий диск 439, накопитель 428 на магнитном диске для считывания с или записи на сменный магнитный диск 429 и накопитель 430 на оптическом диске для считывания с или записи на сменный оптический диск 431 типа CD-ROM или другую оптическую среду. Накопитель 427 на жестком диске, накопитель 428 на магнитном диске и накопитель 430 на оптическом диске связаны с системной шиной 423 интерфейсом 432 накопителя на жестком диске, интерфейсом 433 накопителя на магнитном диске и интерфейсом 434 накопителя на оптическом диске соответственно. Накопители и связанные с ними считываемые компьютером носители обеспечивают энергонезависимое хранение выполняемых компьютером команд, структур данных, программных модулей и других данных для компьютера 420. Хотя приведенная в качестве примера среда, описанная здесь, использует магнитный жесткий диск 439, сменный магнитный диск 429 и сменный оптический диск 431, другие типы считываемых компьютером носителей для сохранения данных могут использоваться, включая магнитные кассеты, платы флэш-памяти, цифровые универсальные диски, картриджи Бернулли, RAM, ROM и т.п.

Программные средства, содержащие один или более программных модулей, могут быть сохранены на жестком диске 439, магнитном диске 429, оптическом диске 431, ROM 424 или RAM 425, включая операционную систему 35, одну или более прикладных программ 36, другие программные модули 437 и данные 438 программ. Пользователь может вводить команды и информацию в компьютер 420 через клавиатуру 440, устройство управления позицией 442 или другие устройства ввода данных (не показаны), такие как микрофон, джойстик, игровую клавиатуру, спутниковую антенну, сканер или подобные. Эти и другие устройства ввода данных часто соединяются с процессором 421 через интерфейс 446 последовательного порта, соединенный с системной шиной 423. Альтернативно устройства ввода данных могут быть подсоединены через другие интерфейсы, например параллельный порт, игровой порт или универсальную последовательную шину (USB). Монитор 447 или другое устройство отображения также связан с системной шиной 423 через интерфейс, например видеоадаптер 448. В дополнение к монитору персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показаны), например, громкоговорители и принтеры.

Компьютер 420 может работать в связанной в сеть среде, используя логические подключения с одним или более удаленными компьютерами, например удаленными компьютерами 449а и 449b. Удаленные компьютеры 449а и 449b могут каждый быть другим персональным компьютером, сервером, маршрутизатором, сетевым PC, одноранговым устройством или другим общим сетевым узлом и обычно включать в себя многие или все элементы, описанные выше, применительно к компьютеру 420, хотя только запоминающие устройства 450а и 450b и их прикладные программы 436а и 436b были проиллюстрированы на фиг.4. Логические соединения, изображенные на фиг.4, включают в себя локальную сеть (LAN) 451 и глобальную сеть (WAN) 452, которые представлены здесь посредством примера, а не ограничения. Такие сетевые среды являются общепринятыми в офисах или компьютерных сетях в масштабах предприятия, интранет и Интернет. При использовании в сетевой среде LAN компьютер 420 связан с локальной сетью 451 через сетевой интерфейс или адаптер 453. При использовании в сетевой среде WAN компьютер 420 может включать в себя модем 454, беспроводное соединение или другие средства для установления связи по глобальной сети 452, типа Интернет. Модем 454, который может быть внутренним или внешним, связан с системной шиной 423 через интерфейс 446 последовательного порта. В связанной в сеть среде программные модули, изображенные применительно к компьютеру 420 или его частям, могут быть сохранены в удаленном запоминающем устройстве памяти. Следует понимать, что показанные сетевые соединения являются только примерами и могут использоваться другие средства установления связи по глобальной сети 452.

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

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

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

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

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

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

2. Способ по п.1, дополнительно содержащий этап:

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

3. Способ по п.2, в котором сохранение состояния сеанса содержит подключаемое хранилище.

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

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

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

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

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

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

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

11. Способ по п.9, дополнительно содержащий этапы:

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

12. Способ по п.9, в котором интервал повторения регулируется интервалом отсрочки после последовательных интервалов повторения.

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

14. Способ по п.1, в котором, по меньшей мере, один подходящий механизм транспортировки сообщений содержит, по меньшей мере, один из следующих механизмов транспортировки: TCP/IP, UDP, HTTP, RPC и SMTP.

15. Способ по п.1, в котором обмен сообщениями задается множеством шаблонов обмена сообщениями, содержащих, по меньшей мере, один из: односторонняя передача сообщений, передачи сообщений с запросом/ответом и полно-дуплексная передача сообщений.

16. Машиночитаемый носитель, хранящий выполняемые компьютером команды, которые

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

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

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

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

17. Машиночитаемый носитель по п.16, в котором способ дополнительно содержит этап:

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

18. Машиночитаемый носитель по п.17, в котором сохранение состояния сеанса содержит подключение хранилища.

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

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

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

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

23. Машиночитаемый носитель по п.22, в котором протокол копирует принятое сообщение в буфер приема.

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

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

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

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

28. Машиночитаемый носитель по п.26, дополнительно содержащий этапы:

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

29. Машиночитаемый носитель по п.16, способ дополнительно содержащий действие:

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

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

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

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

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

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

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

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

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

36. Способ по п.33, в котором свойство локальной надежной передачи сообщения транзактной поддержки доступно независимо от длительности хранения состояния сеанса.

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

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

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

40. Способ по п.38, в котором буферы состояния сеанса содержат буфер приема, который сохраняет сообщения, пока они не будут доставлены приложению.

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

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

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

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

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

46. Способ по п.37, в котором состояние для канала, буферов состояния сеанса и протокол поддерживаются в подключаемом хранилище.

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

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

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

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

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

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

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

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

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

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

55. Машиночитаемый носитель по п.53, в котором информация о состоянии содержит, по меньшей мере, одно из: порядковый номер передачи и информация о состоянии подтверждения.

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

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

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

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

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

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

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

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

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

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

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

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

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

65. Машиночитаемый носитель по п.64, в котором интервал повторения регулируется интервалом отсрочки после последовательных интервалов повторения.

66. Машиночитаемый носитель по п.61, в котором способ дополнительно содержащий действие планирования передачи, по меньшей мере, одного сообщения из последовательности сообщений к оконечной точке партнера.

67. Машиночитаемый носитель по п.66, в котором планирование основано на, по меньшей мере, одной из: неустойчивой связности, балансировки нагрузки, приоритете сообщений, и использование механизма транспортировки более низкой стоимости.

68. Машиночитаемый носитель по п.63, в котором состояние для канала,

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

69. Машиночитаемый носитель по п.61, в котором обмен сообщениями определен множеством шаблонов обмена сообщения, содержащих, по меньшей мере, одно из: односторонняя передача сообщений, передача сообщений с запросом/ответом, и полно-дуплексная передача сообщений.