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

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

Иллюстрации

Показать все

Реферат

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

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