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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другим свойством, обеспе