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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг.2 иллюстрирует оболочку сообщения в соответствии с примерными вариантами выполнения настоящего изобретения;

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

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

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

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

После записи заголовка сеанса и последовательности в сообщение 191 и выполнения остальной требуемой канальной обработки сообщение 191 сохраняется в сеансовом состоянии 190 в буфере отправки. Вслед за этим копия сообщения 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 сеансового состояния (принять) посредством своей команды Принять(). Если оболочка 120 надежного обмена сообщениями не принимает подтверждающее сообщение 192, потому что оно выпало, задержано или направлено не туда, то переотправка сообщения 191 будет продолжаться, тем самым запуская оболочку 180 надежного обмена сообщениями отправить копию подтверждения сообщения 192. Этот процесс может продолжаться до тех пор, пока, по меньшей мере, одно подтверждение 192 не будет принято оболочкой 120 надежного обмена сообщениями, или же пока оболочка 120 надежного обмена сообщениями не откажется от повторных попыток и не отправит индикацию отказа к приложению 105.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с примерными вариантами выполнения и как описано ниже со ссылкой на фиг.2, на конечном пункте отправителя, когда вызывается функция Отправить() 210, сообщение предварительно помещается в диалоговую память 260. Если транзакция совершается, сообщение передается в память 260 и делается доступным для передачи к партнерскому конечному пункту. Если транзакция прерывается, сообщение отбрасывается. У получателя, когда вызывается функция Получить() 215 (или Стереть), сообщение предварительно стирается из диалоговой памяти 260. Если транзакция совершается, сообщение постоянно стирается из памяти 260. Если же транзакция прекращается, сообщение остается в памяти 260 и доступно для повторной доставки. Получение в процессе транзакции обеспечивает в точности одну обработку сообщений.

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

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

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

Поскольку диалог 200 обеспечивает любую комбинацию этих признаков и гарантий независимо один от другого, диалог 200 может конфигурироваться, чтобы удовлетворять любой связывающей конфигурации от тесно связанных программных моделей, подобных протоку управления передачей (ТСР) и вызову удаленной процедуры (RPC), до свободно связанных программных моделей, подобных дейтаграммам и очередям. В дополнение к этому, диалог 200 эффективно поддерживает различные двусторонние схемы обмена сообщениями (МЕР), такие как однонаправленные, полудуплексные (от единичного запроса/ответа до более сложных схем) и наиболее сложные полнодуплексные взаимодействия. Соответственно, диалог 200 позволяет унифицировать двусторонние программные модели связи. Фиг.2 иллюстрирует операционные признаки диалога 200 в соответствии с примерными вариантами выполнения настоящего изобретения. Диалоговый канальный интерфейс прикладного программирования (ИПП) (API) 220 предусматривается как реферат для приложения 205. Как обсуждалось ранее, диалог 200 использует протокол обмена сообщениями, такой как сетевые услуги - надежный обмен сообщениями (СУ-НОС) (WS-RM), который определяет последовательность сообщений. Последовательность определяет однонаправленный набор сообщений в сеансе. Две таких последовательности объединяются для образования диалога, по одной последовательности в каждом направлении между двумя осуществляющими связь сторонами. Когда вызывается функция Отправить() 210 каналу 220, сообщение, которое проходит в качестве параметра к функции Отправить 210, сохраняется в состоянии 250 отправки и единственным образом характеризуется монотонно возрастающим номером последовательности сообщений согласно порядку, в котором сообщение было послано.

Сообщения 255 буферизуются в состоянии 250 отправки для поддержания состояния отдельных сообщений 255 в последовательности. При этом говорят, что сообщения «захватываются» в состоянии 250, а функция Отправить() 210 возвращается в приложение. Конкретнее, функция Отправить 210 принимает одно сообщение в качестве параметра. Именно это сообщение проходит к буферу 250 отправки, чтобы быть охарактеризованным номером последовательности и последовательно или одновременно сохраняться в памяти 260. Именно при этом сообщение считается «захваченным», а способ Отправить 210 возвращается. Повторение этого вызова с остальными сообщениями приводит к последовательности или частичной последовательности сообщений 255.

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

Когда сообщение захвачено, протокол 270 может затем обрабатывать и передавать захваченное сообщение, например, сообщение 275, соответственно через порт 285. Программная модель и инфраструктура этапа выполнения для диалога 200 обеспечивают гибкую и эффективную модель разрешения конечного пункта.

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

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

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

Протокол 270 также определяет, какой тип сквозной гарантии и локальных признаков конкретизируется приложением 205 независимо от способа выполнения описанного выше разрешения конечных пунктов. Если приложение 205 устанавливает гарантию ХБО, протокол 270 содержит копию сообщения 275 в диалоговом буфере 250 отправки до тех пор, пока этот протокол 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 приема. В частности, к приложению 205 посылается извещение, что сообщение доступно для получения. Приложение 205 может тогда вызвать функцию Получить() 215, после чего следующее сообщение, доступное для доставки, проходит к приложению 205, и «доставка» считается состоявшейся.

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

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

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

Все состояния для диалога 200, в том числе и имеющиеся в буферах 250 и 240, в канале 220 и в протоколе 270, могут поддерживаться одновременно в диалоговой памяти 260. Эта диалоговая память 260 должна содержать наиболее свежую информацию. Это гарантирует, что диалоговое состояние 235 имеет долговечные свойства диалоговой памяти 260, и позволяет всем признакам функционировать безотносительно к памяти 260, которая находится в пользовании. К примеру, помещение сообщения 280 в буфер 240 получения может включать в себя дисковые записи в память 260. Для того чтобы обеспечить гарантии, подтверждения посылаются только после того, как сообщение записано в память 260. Это гарантирует, например, что либо отправитель, либо получатель всегда имеют копию этого сообщения. Аналогично, на отправляющей стороне, функция Отправить() будет завершаться только после того, как сообщение запишется в память 260.

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

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

Вдобавок, и как упомянуто выше, приложение 205 может устанавливать, что функции Отправить() 210 или Получить() 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 находится в памяти, в противном случае диалог 200 находится в неактивном состоянии 360 и диалог 200 существует только в диалоговой памяти 260. Управление системными ресурсами происходит через процессы деактивации 350 и реактивации 340, которые могут происходить вручную или автоматически. К примеру, деактивация 350 может происходить вручную, если приложение вызывает функцию Разместить, или автоматически из-за времени бездействия, когда истекает некоторый период времени, в котором нет обмена сообщениями по диалоговому каналу. Такой канал можно деактивировать (соответствующие объекты убираются из памяти), тем самым освобождая ресурсы памяти для другого.

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

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

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

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

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

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

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

Компьютер 420 может также содержать дисковод 427 магнитного жесткого диска для считывания с магнитного жесткого диска 439 и записи на него, дисковод 428 магнитного диска для считывания со съемного магнитного диска 429 или записи на него, и дисковод 430 оптического диска, такого как ПЗУ-КД или иного оптического носителя, для считывания со съемного оптического диска 431 или записи на него. Дисковод 427 магнитного жесткого диска, дисковод 428 магнитного диска и дисковод 430 оптического диска подключаются к системной шине 423 интерфейсом 432 дисковода жесткого диска, интерфейсом 433 дисковода магнитного диска и интерфейсом 434 оптического дисковода, соответственно. Дисководы и связанные с ними машиночитаемые носители данных обеспечивают энергонезависимую память для исполняемых компьютером команд, структур данных, программных модулей и других данных для компьютера 420. Хотя описанная здесь примерная среда использует магнитный жесткий диск 439, съемный магнитный диск 429 и съемный оптический диск 431, можно использовать и другие типы машиночитаемых носителей данных для хранения данных, в том числе магнитные кассеты, карты флэш-памяти, цифровые многоцелевые диски, картриджи Бернулли, ОЗУ, ПЗУ и т.п.Программное кодовое средство, содержащее один или более программных модулей, в том числе операционную систему 435, одну или более прикладных программ 436, другие программные модули 437 и программные данные 438, может храниться на жестком диске 439, магнитном диске 429, оптическом диске 431, в ПЗУ 424 или ОЗУ 425. Пользователь может вводить команды и информацию в компьютер 420 через клавиатуру 440, координатное устройство 442 или иные устройства ввода (не показаны), такие как микрофон, джойстик, игровая панель, спутниковая антенна, сканер или аналогичные. Эти и другие устройства ввода часто соединяются с блоком 421 обработки через интерфейс 446 последовательного порта, связанный с системной шиной 423. Альтернативно, устройства ввода могут подключаться другими интерфейсами, такими как параллельный порт, игровой порт или универсальная последовательная шина (УПШ) (USB). Монитор 447 или иное устройство отображения также подключено к системной шине 423 через интерфейс, такой как видеоадаптер 448. В дополнение к монитору, персональные компьютеры, как правило, включают в себя другие периферийные устройства вывода (не показаны), такие как громкоговорители и принтеры.

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

При использовании ЛС компьютер 420 соединяется с локальной сетью 451 через сетевой интерфейс или адаптер 453. При использовании ГС компьютер 420 может включать в себя модем 454, беспроводную линию или другие средства для установления соединений по глобальной сети 452, такой как Интернет. Модем 454, который может быть внутренним или внешним, подключается к системной шине 423 через интерфейс 446 последовательного порта. В сетевой среде программные модули, показанные относящимися к компьютеру 420, или их части могут храниться в удаленном запоминающем устройстве. Понятно, что показанные сетевые соединения являются примерными, и что могут использоваться и другие средства установления связи по глобальной сети 452.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. Способ по п.16, по которому локальный признак надежного обмена сообщениями в виде памяти сеансового состояния содержит съемную память.

18. Способ по п.17, по которому память содержит по меньшей мере одну из встроенной памяти, долговременной дисковой памяти или памяти процесса демона.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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