РЕАЛИЗАЦИЯ СОВМЕСТНО ИСПОЛНЯЮЩИХСЯ ПРОГРАММ НА ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ЯЗЫКАХ Российский патент 2010 года по МПК G06F9/45 

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

Объектно-ориентированные (ОО) оболочки, например, сред торговых марок J2EE и.NET сделали OO-подход к разработке программ широко распространенным. Однако из-за его сосредоточенности на разделяемой памяти он ведет к сложной поддержке совместного исполнения, поддержка, которая лучше подходит для системного программирования, чем для прикладного программирования. Повсеместно признано, что разделяемая память является одним из главных препятствий для поддержки совместного исполнения.

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

Традиционные службы с передачей сообщений определены языком Оккам, специализированным языком, разработанным в 80-х, который был разработан и работоспособен только на специализированном аппаратном процессоре. Формальные программные спецификации, встроенные в язык программирования, не новы. Eiffel, например, предлагает ограниченную разновидность поддержки программной спецификации непосредственно в самом языке программирования. Eiffel является продвинутым языком программирования, созданным Бертраном Мейером и развитым его компанией, Interactive Software Engineering (ISE - Разработка интерактивных программ).

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

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

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

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

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

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

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

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

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

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

Для облегчения понимания описанные аспекты настоящего изобретения обращены к концепциям языка Visual Basic (VB), имеющим отношение к следующим ключевым словам: служба (Service), отправка (Send), прием (Receive), избирательный прием (Select Receive), ожидание (Wait), расщепление (Split), таймаут (Timeout), внутренние службы (Inner Services), начало (Begin), перехваченный прием (Catch Receive), согласиться (Accept), расщепленный выборочный прием (Split Select Receive). Комбинированная новая языковая конструкция может реализовать модель для обработки сообщений параллельно друг с другом. Предполагается, что настоящее изобретение может поддерживать слабосвязанное совместное исполнение и совместные процедуры для сильно связанного параллелизма. Эти конструкции обсуждены более подробно далее по тексту.

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

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

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

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

Фиг.3 иллюстрирует обобщенную компонентную структурную схему компонента контракта в соответствии с аспектом изобретения.

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

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

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

Фиг.7 иллюстрирует структурную схему компьютера, способного приводить в исполнение раскрытую архитектуру.

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

Приложение А - документ, озаглавленный «Беступиковое соответствие» («Stuck-Free Conformance»). Это приложение формирует часть патентного описания.

Осуществление изобретения

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

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

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

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

Обратимся к фиг.1, где показана обобщенная структурная схема объектно-ориентированной системы 100 в соответствии с аспектом настоящего изобретения. Как указывалось ранее, для облегчения понимания система 100 будет описана в настоящем патентном документе ориентированной на приложения VB. Несмотря на то, что, главным образом, VB-среда будет использована для обсуждения аспектов изобретения, должно быть принято во внимание, что система 100 может быть применена к любому известному объектно-ориентированному языку, не выходя за рамки объема изобретения, описанного в настоящем патентном документе. В целом, система 100 может быть сконфигурирована с возможностью включения в себя клиента 102, компонента 104 контракта, компонента 106 оркестрации и нескольких целевых служб 108₁-108_N, где N - целое число. Очевидно, что целевые службы 108₁-108_N могут в дальнейшем коллективно указываться ссылкой как целевые службы 108.

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

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

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

На этапе 202 объявлен контракт, как описано в настоящем патентном документе, очевидно, что объявление контракта может включать в себя определение нескольких сообщений или методов, а также необязательный шаблон ввода в действие. На этапе 204 сообщения (или методы), воплощенные в контракте, отправлены целевой службе. Затем на этапе 206 сообщение (или методы) принято, и спровоцирован переход. В заключение, сообщение согласуется на этапе 208 и впоследствии разбирается на этапе 210, для того чтобы реализовать контракт и применить код, заключенный в этом сообщении(ях) и/или методе(ах).

Модель совместного исполнения

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

Вопреки традиционным реализациям в примерной VB-оркестрации настоящего изобретения, проиллюстрированной на фиг.1, нет двух линий исполнения, которые разделяют состояние «в памяти», исполняющихся совместно. Как проиллюстрировано, настоящее изобретение применяет службы 108 для содействия совместному исполнению. Службы не разделяют состояние с любым кодом вне отдельной службы. Дополнительно, чтобы выполнить асинхронный обмен данными, настоящая система, проиллюстрированная на фиг.1, использует компонент 104 контракта или технологию «передачи сообщений», которая появляется в языке в качестве явно указанных операций Send и Receive и осуществлялась в пределах компонента 106 оркестрации.

Очевидно, что введение асинхронной передачи сообщений требует механизмов для управления передачей данных одновременно между многочисленными службами. Поэтому набор механизмов для координирования передачи данных между совместно исполняемыми службами обозначен термином «оркестрация» и применен компонентом 106 оркестрации по фиг.1.

Как будет более подробно обсуждено ниже, предусмотрены языковые механизмы, которые вводят псевдопараллельное исполнение (например, Split). Однако эти механизмы фактически обеспечивают совместное ожидание, нежели совместное исполнение. Сочетание служб 108 и компонента 106 оркестрации обеспечивает совместное и асинхронное поведение, исключая опасности ситуации «состязания» и не синхронизированного доступа к памяти. В соответствии с настоящим изобретением обмен сообщениями между двумя службами происходит в качестве диалога, управляемого компонентом 104 контракта. Компонент 104 контракта предоставляет спецификацию поведений при обмене сообщениями служб 108 и предоставляет возможность проверить отдельную службу 108 на некоторые виды корректности (например, соответствие шаблонам обмена сообщениями, свободу от зависания), не осуществляя доступ к реализациям служб, с которыми она взаимодействует. Таким образом, очевидно, что первичным средством идентификации в понимании поведения службы является ее реализуемый контракт.

Контракты

Как показано на фиг.3, по существу контракт 104 может быть определен как объявления интерфейса для асинхронной передачи сообщений с более богатой семантикой. Другими словами, контракт, использующий компонент 302 сообщения для задания набора сообщений (или методов) и необязательного шаблона или компонента 304 шаблона, который описывает допустимые последовательности обмена сообщениями. Дополнительно компонент 104 контракта может применять компонент 306 расширения контракта, который расширяет существующий компонент контракта.

Фиг.4 иллюстрирует методологию 202 для объявления контракта в соответствии с различными аспектами настоящего изобретения. Как описано в настоящем патентном документе, является очевидным, что объявление контракта может включать в себя определение большого количества сообщений или методов, а также необязательного шаблона. Ссылаясь на фиг.4 и приступая к этапу 402, объявлен тип контракта. Более точно, в соответствии с VB-примером, объявление контракта создает два VB-типа, представляющих ракурсы клиента и сервера по контракту. Например, объявление «Contract C» создает тип «С», (представляющий ракурс клиента), и тип «Implements C», (представляющий ракурс сервера). В качестве примера последующее является иллюстративным контрактом для службы будильника.

Contract AlarmClock

In Message Set(t As TimeSpan)

In Message Cancel()

Out Message Alarm()

Pattern

Start:

Set -->Alarm Set

AlarmSet:

Cancel -->End

Alarm -->AlarmSet

End Pattern

End Contract

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

Contract SnoozeAlarmClock

In Message Snooze 0

Pattern

AlarmSet:

Snooze -->AlarmSet

End Pattern

End Contract

Для того чтобы обеспечить контекст и для облегчения понимания, далее обсуждена грамматика и семантика контракта. В качестве примера,

Как обсуждено ранее со ссылкой на фиг.3, контракт может задавать набор сообщений 302 и необязательно шаблон 304, описывающий допустимые последовательности обмена сообщениями, и/или расширение 306 контракта, как проиллюстрировано на фиг.3. Необходимо отметить, что, если шаблон 304 не задан, то любые последовательности заданных сообщений разрешены. Механизм 306 расширения контракта предназначен для дополнения (усиления) контракта, с тем чтобы был возможен диалог между соединителем, типизированным с использованием усовершенствованного контракта, и соединителем, типизированным с использованием совершенствующего контракта.

Вновь обращаясь к фиг.4 и переходя к этапу 404, может быть объявлено сообщение. Затем на этапе 406 по выбору может быть задан шаблон. Шаблон, заданный на этапе 406, может быть задан как конечный автомат.Состояния могут быть поименованы посредством меток в StateTransitionStatementGroups. В приведенном выше примере будильника начальное состояние названо «start». Отправки и приемы сообщений, а также исполнения других контрактов вызывают переходы в конечном автомате. Предполагается, что, если StateTransitionStatementGroup (группа операторов переходов состояния) включает в себя более чем один StateTransitionStatement, то модель предоставляет возможность любого одного из переходов в группе.

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

В соответствии с примером, состояние

S0:

M1 then M2 -->S2

является эквивалентным для

M0 -->S1

S1 -->S2

Подобным образом состояние

S0:

M1 Or M2 -->S2

является эквивалентным для

S0:

M1 -->S2

M2 -->S2

Дополнительно состояние

S0:

M1 And M2 -->S3

является эквивалентным для

S0:

M1 -->S1

M2 -->S2

S1:

M2 -->S3

S2:

M1 -->S3

Специалисты в данной области техники признают, что «Or» («Или»), «And» («И») и «Then» («Затем») имеют такое же отношение предшествования, как соответственно «Или», «И» и «А также» в синтаксисе выражения.

В одном из аспектов инициирующее событие, заданное как «In Message» («Входящее сообщение») или «Out Message» («Исходящее сообщение») может представлять любое сообщение, объявленное в контракте, следующее в определенном направлении. В другом аспекте инициирующее событие, заданное как «Any In Message» («любое входящее сообщение») или «Any Out Message» («любое исходящее сообщение») представляет любое сообщение, следующее в определенном направлении, и может быть сообщением, не объявленным в контракте.

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

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

Как показано на фиг.4, в соответствии с представленными системой и способом, сообщения могут быть отправлены и приняты через соединения. Соединением является элемент данных с типом, который является типом контракта, объявленным на этапе 402. Очевидно, что тип контракта может быть задан посредством именования контракта. С другой стороны, соединение может быть элементом данных с типом, который является типом принадлежностей контракта. Типы принадлежностей контракта могут быть заданы посредством продолжения наименования контракта обозначения «Implements» («Принадлежности»). Соединение с типом контракта может отправлять входные (In) сообщения и принимать выходные (Out) сообщения. Соединение с типом принадлежностей контракта может отправлять выходные (Out) сообщения и принимать входные (In) сообщения.

Расщепленные переходы

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

В качестве примера:

Шаблон

Start:

M1 -->Start And

M2 -->S2

S1:

M3 -->S3

S2:

M4 -->S3

S3:

M5 -->End

End Pattern

согласует последовательность сообщений M1, M1, M2, M4, M3, M4, M5. Каждый расщепленный переход, который включает в себя S1, требует M3 для перехода к состоянию S3 слияния, значит может быть одинаковое количество сообщений M1 и M3.

Шаблон

Pattern

Start:

Con1 -->Immediate S1 And S2

S1:

M1 -->End

S2:

M2 -->End

End Pattern

предоставляет M1 возможность быть смешанным с сообщениями Con1, но требует, чтобы M2 происходил после того, как Con1 завершается. Должно быть отмечено, что эта модель также иллюстрирует, что End может быть состоянием слияния.

Расширение контракта

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

Пример грамматики и семантики изложен ниже.

ExtendsStatement →

EXTENDS Name

Здесь наименование (name) в операторе Extends может именовать контракт, который не является содержащим контрактом, или контракт, который расширяет или уточняет содержащий контракт.

Если контракт B расширяет контракт A, то:

- Все сообщения А являются сообщениями B.

- Все состояния А являются состояниями B.

- Все контракты, принадлежащие А принадлежат В.

- В не может удалять любые переходы из состояний, которые он унаследовал от А.

- В может добавлять сообщения, состояния и размещенные контракты.

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

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

Соединители

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

Оркестрация

Помимо этого, операция Split (расщепить) вырабатывает многочисленные линии исполнения, любая из которых исполняется до тех пор, пока она не выдаст результат, в точке которого любая из других может запускаться. Различные операции языка могут мотивировать обеспечение линией исполнения до выдачи результата. Среди них Receive (например, ожидает сообщения, которое должно прибыть) и Wait (например, ожидает заданный интервал времени).

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

Класс оркестрации объявлен модификатором «orchestration» («оркестрация»). Класс оркестрации не может содержать разделяемые методы или свойства. В соответствии с аспектом операции оркестрации являются VB-операторами и, допуская некоторые ограничения, могут появляться в любом методе.

Снова со ссылкой на фиг.2 на этапе 204 оператор Send может быть сконфигурирован, как приведено ниже.

SendStatement →

SEND [TO Expression] SendMessageDescriptor

SendMessageDescriptor →

SendSpecificMessage |

SendMessage

SendSpecificMessage →

Identifier [(Arguments)]

SendMessage →

MESSAGE Expression

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

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

Если представлено ключевое слово Message (Сообщение), то выражение может быть преобразуемым в System.MessageBus.Message и идентифицирует объект сообщения, которое должно быть отправлено.

Подобным образом на этапе 206 оператор Receive может быть сконфигурирован, как изложено ниже:

ReceiveStatement →

ReceiveClause

ReceiveClause →

RECEIVE [FROM Expression] ReceiveMessageDescriptor [WHEN Expression]

ReceiveMessageDescriptor →

ReceiveSpecificMessage [ReceiveMessage]|

ReceiveMessage

ReceiveSpecificMessage →

Identifier [({ReceiveParameterList})]

ReceiveMessage →

MESSAGE ReceiveParameter

ReceiveParameterList →

ReceiveParameter {,ReceiveParameterList}

ReceiveParameter (

Identifier [AS GeneralType]

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

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

К тому же, когда представлено, выражение When в Receive действует в качестве двоичного фильтра. Если представлено выражение фильтра, то сообщение принимается, если фильтр вычисляет значение True, и в противном случае оно игнорируется до тех пор, пока какой-либо другой Receive его не употребит.Выражение фильтра может осуществлять доступ к параметрам условия приема, к которому оно прикреплено, и элементам принимаемого сообщения, но не к другим, неконстантным объявлениям. Отсутствующее выражение фильтра эквивалентно выражению фильтра, которое всегда имеет значение «True» («Истина»).

К примеру, оператор Receive в виде

Receive From С Mumble(P As T)

NextStatement()

эквивалентен по отношению к

Dim P As T

Select Receive

Case Receive From С Mumble (P)

End Select

NextStatement()

Оператор Wait может быть сконфигурирован, как изложено ниже.

WaitStatement →

WAIT Expression

Оператор Wait блокирует исполнение на определенный интервал, заданный выражением (Expression), который может быть типа System.TimeSpan. Оператор Wait в виде

Wait Span

NextStatement()

эквивалентен по отношению к

Select Receive Within Span

Case TimeOut

End Select

NextStatement()

Примечание: важно, что Threading.Thread.Sleep() не используют внутри кода оркестрации, поскольку он может блокировать поток, не позволяя другой линии в оркестрации запускаться.

По приему может быть выполнен переход. Оператор Begin может быть сконфигурирован, как приведено ниже.

BeginStatement →

BeginClause

BeginClause →

BEGIN Identifier TypeAndInitializer

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

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

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

Оператор Begin вида

Begin Cl As New CT(C0)

NextStatement()

эквивалентен

Dim Cl As CT

Select Receive

Case Begin Cl=New CT(CO)

End Select

NextStatement()

В заключение на этапе 208 может быть согласовано сообщение. Следовательно, Accept State Statement (оператор согласования состояния) может быть сконфигурирован, как изложено ниже.

AcceptStateStatement →

AcceptStateClause

AcceptStateClause →

ACCEPT [FROM Expression] Identifier

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

Оператор согласования состояния не употребляет какие-либо сообщения. В частности, не употребляется сообщение, которое вызвано переходом состояния. Снятие блокировки требует перехода состояния. Если соединение уже находится в именованном состоянии, когда оператор согласования состояния начался, то оператор согласования состояния ожидает до тех пор, пока соединение повторно введет состояние.

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

Оператор согласования состояния в виде

Accept From С S

Nextstatement()

эквивалентен по отношению к

Select Receive

Case Accept From С S

End Select Nextstatement()

Select Receive Statement (оператор выборочного приема) может быть сконфигурирован, как изложено ниже.

SelectReceiveStatementGroup →

SelectReceiveStatement {CaseReceiveStatement {ExecutableStatement}}[CaseTimeoutStatement {ExecutableStatement})EndSelectStatement

SelectReceiveStatement →

SELECT RECEIVE [WITHIN Expression]

CaseReceiveStatement →

CASE CaseReceiveClause {, CaseReceiveClause }

CaseReceiveClause →

ReceiveClause |

BeginClause |

AcceptStateClause

CaseTimeoutStatement →

CASE TIMEOUT

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

Если более чем один CaseReceiveClause представлен в CaseReceiveStatement, то все условия могут быть удовлетворены для запуска исполнения тела кода, ассоциативно связанного с каркасом (case).

Оператор Split может быть сконфигурирован, как изложено ниже.

SplitStatementGroup →

SplitStatement { SplitLineStatement {ExecutableStatement}] EndSplitStatement

SplitStatement →

SPLIT

EndSplitStatement →

END SPLIT

SplitLineStatement →

LINE

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

Split For Each Statement («оператор расщепления для каждого») может быть сконфигурирован, как изложено ниже.

SplitForEachStatementGroup →

SPLIT ForEachClause { ExecutableStatement} NextStatement

Тело SplitForEachStatementGroup может быть исполнено, как если бы каждая итерация была отдельной линией из SplitForEachStatementGroup. Полная итерация по набору может совершаться перед исполнением тела.

Split Select Receive Statement (оператор расщепления выборочного приема) может быть сконфигурирован, как изложено ниже.

SplitSelectReceiveStatemenlGroup →

SPLIT SelectReceiveStatement { CaseReceiveStatement {ExecutableStatement } } [CaseTimeoutStatement {ExecutableStatement} J EndSelectStatement

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

Split Select Receive

Case Receive M From С

Receive Ml From С

End Select

подобен, однако, едва различимо и значительно отличен от

Do

Split Select Receive

Case Receive M From С

Receive Ml From С

End Select

Loop

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

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

CatchReceiveStatement →

CATCH ReceiveClause

Catch Accept State Statement (оператор захвата согласования состояния) может быть сконфигурирован, как изложено ниже. Оператор попытки может иметь обработчики, которые согласовывают состояния соединений. Новый вид оператора захвата бывает использован для реализации этой концепции.

CatchAcceptStateStatement →

CATCH AcceptStateClause

Предусмотрены новые операторы выхода (Exit Statement). Например, новыми разновидностями выхода могут быть Line и Split. Они применяются в пределах операторов Split, Split For Each и Split Select Receive и недопустимы в каком-либо другом месте. Оператор Exit Line может завершать линию исполнения в Split. Оператор Exit Split может выходить из Split и завершать все другие линии Split.

Любые другие передачи управления, которые выходят из любого вида Split, могут иметь семантику Exit Split, а не семантику Exit Line.

Службы

Вновь обращаясь к фиг.2, далее контракт реализуется на этапе 210. В соответствии с настоящим изобретением служба (например, служба 108 по фиг.1) обеспечивает реализацию контракта. Служба подвергается обработке автоматически по приему инициирующего сообщения контракта службы. Соединитель, через который служба реализует свой контракт, инициализирован автоматически, напрямую пригоден для отправки и приема сообщений и может быть указан ссылкой напрямую как «Primary» («Первичный»). В соответствии с описанным аспектом служба может иметь экземпляр метода, называемый «Run» («Запустить»), который не имеет параметров и возвращает результат, таким образом, активизация службы вызывает Run.

Службой является класс оркестрации, который порождается непосредственно или опосредованно из RuntimeService. Если базовый класс не определен, то он представляет собой непосредственно RuntimeService.

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

Service DecentAlarmClock

Implements AlarmClock

Sub Run()

Receive Set(T As TimeSpan)

Select Receive Within T

Case Receive Cancel ()

Case TimeOut

Send Alarm()

Receive Cancel()

End Select

End Sub

End Service

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

Service NicerAlarmClock

Implements SnoozeAlarmClock

Sub Run()

Receive Set(T As TimeSpan)

Do

Try

Wait T

Send Alarm()

Receive Snooze ()

T=Snoozelnterval

Catch Receive Cancel()

Return

End Try

Loop

End Sub

End Service

Обращаясь далее к грамматике и семантике службы:

ServiceStatementGroup →

ServiceStatement { ServiceMemberStatement } EndServiceSiatement

ServiceStatement →

SERVICE Identifier

EndServiceStatement →

END SERVICE

ServiceMemberStatement →

ServiceStatement |

MessageStatement |

ClassMemberStatement

В соответствии с вышеприведенным служба не может иметь и оператор принадлежностей, и какие-либо операторы сообщений. Однако, если оператор принадлежностей представлен, то он будет один, он может именовать единственный тип, и такой тип может быть контрактом.

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

Первичный соединитель может быть доступен в пределах службы в качестве Primary. Если выражение соединителя не включено в оператор Send или Receive, то соединитель может быть первичным неявно.

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

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

Контракты

Снова ссылаясь на контракты в общем случае, контракты могут быть использованы в ОО-языках (например, VB), чтобы задавать протокол и его сообщения. Это решение будет сосредотачиваться на трех частях: операторах импорта контракта, операторах объявления сообщения и операторе определения одиночного шаблона, как показано далее:

Contract CtRequestResponse

In Message Request(Question As String)

Out Message Response(Answer As String)

Pattern

Start:

Request Then Response (End

End Pattern

End Contract

Вышеприведенное является определением входящего сообщения, названного «Request», которое переносит строку String. Подобным образом определено исходящее сообщение, названное «Response», которое также переносит строку String. Заметим, что само сообщение является наименованием, а не «скоплением» данных. Точнее, само сообщение является идентификатором для него, подобно наименованию класса в таком рассмотрении. Данные могут быть определены в качестве параметров сообщения.

В дополнение также определено, что протокол предоставляет возможность только двух сообщений в любом из «сеансов»: запроса (Request) или ответа (Response). Направления двух сообщений при взаимодействии подразумеваются соответственным объявлением сообщения. Будет принято во внимание, что исходящее сообщение одного субъекта является исходящим сообщением другого субъекта. В соответствии с настоящим изобретением этот ракурс происходит из ракурса службы, которая реализует контракт.

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

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

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

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

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

Объявления сообщений

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

1. Не допускаются все параметры, которые являются объявлениями «ByVal», «Optional», «ByRef» или «ParamArray».

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

3. Все сообщения обязаны иметь указанное направление.

4. Сообщения не могут быть перегружены.

Объявления шаблона

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

Шаблоны объявляются посредством определения множества именованных «состояний» протокола, например, разных позиций в диалоге, которые имеют некоторое значение для него. Первое состояние любого шаблона может быть названо «Begin». Как только состояния определены, протокол может быть завершен добавлением «переходов» состояний, чтобы показать, как состояния протокола могут изменяться. Будет принято во внимание, что инициирующие сигналы могут быть идентифицированы в связи с действиями этапов 408 и 410. В одном из аспектов такие переходы инициируются сообщениями. В других аспектах сообщения могут быть представлены методами или импортированным контрактом.

В качестве примера

Contract CtRequestResponse

In Message Request(Question As String) Out Message Response(Answer As String) 15

Pattern

Start:

Request Then Response (End

End Pattern

End Contract

Как изложено выше, выражение «Request Then Response» («запрос, затем ответ») является инициирующим сигналом перехода, а «End» («конец») - конечным состоянием перехода. Инициирующие сигналы переходов, другими словами, могут быть составными. Например, составные инициирующие сигналы перехода могут быть применены как посредством упорядочивания множества сообщений с использованием «Then» («затем»), так и посредством неупорядоченного группирования их с использованием «And» («И»). К тому же, также возможно задать альтернативное множество инициирующих сигналов, используя «Or» («или») между наименованиями сообщений. Переход происходит, как только все сообщения инициирующего сигнала были отправлены или приняты.

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

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

Расширение контракта

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

1. Не могут быть введены никакие неоднозначности.

2. Никакое из существующих инициирующих состояний не может быть удалено.

3. Инициирующие сигналы, добавленные к существующим состояниям, не могут иметь одновременно сообщения «In» (входящие) и «Out» (исходящие) в качестве первых возможных сообщений, направление сообщения должно быть таким же.

4. Если инициирующий сигнал добавлен к существующему состоянию и если инициирующий сигнал является сообщением «In», то все инициирующие сигналы, добавленные к любому существующему состоянию, содержат в себе только сообщения «In».

5. Наоборот, если инициирующее сообщение добавлено к существующему состоянию и если инициирующий сигнал является сообщением «Out», то все инициирующие сигналы, добавленные к любому существующему состоянию, могут содержать только сообщения «Out».

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

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

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

Нижеследующее является примерами, применяющими модифицированную версию ранее представленного примера запроса/ответа:

Contract CtRequestResponse

In Message Request{Question As String)

Out Message Response(Answer As String)

Pattern

Start:

Request (S1

S1:

Response (End

End Pattern 20

End Contract

Совместимый с клиентом пример:

Contract CtRequestResponse1

Extends CtRequestResponse

In Message Requestlnt(Question As String)

Out Message Responselnt(Answer As Integer)

Pattern

Start:

RequestInt (S2

S2:

ResponseInt (End

End Pattern

End Contract

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

Совместимый со службой пример:

Contract CtRequestResponse2

Extends CtRequestResponse

Out Message Responselnt(Answer As Integer)

Pattern

S1:

Responselnt (End

End Pattern

End Contract

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

Будет понятно, что контракт A может расширять контракт B посредством сложения размещенных контрактов и не используя сообщения. В этом случае A является симметрично совместимым с B. Размещение контрактов будет более подробно обсуждено далее в этом тексте.

Соединители

Контракты могут применяться для того, чтобы объявлять что-либо, что указывает ссылкой на них. В соответствии с иллюстративными аспектами объект, основанный на VB-оркестрации, код которого используется, чтобы обмениваться данными с другим кодом, называют «Соединитель» («Connector»).

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

Соединители могут быть созданы с использованием фабрик соединителей, которые могут быть определены рабочим циклом (например, рабочим циклом VB). Большинство фабрик соединителей созданы из URL-служб или других соединителей.

Dim cFact As ConnectorFactory(Of CtRequestResponse)=ServiceURL

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

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

Dim Connector_l As CtRequestResponse=cFact

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

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

Dim cFact As ConnectorFactory(Of CtRequestResponse)=Connector_4

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

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

Dim Connector_4 As Implements Ordering=Ordering()

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

Заметим, что служба, как определено ранее, имеет неявный реализующий соединитель, называемый его «первичным» соединителем. Он создан алгоритмом рабочего цикла до того, как служба запущена, и пригоден для регламента в качестве поля «Primary». При отправке и приеме сообщений первичный соединитель может быть выражен неявно, когда нет других соединителей, которые указаны ссылкой, поэтому редко наблюдается любой код, который на самом деле явно ссылается на первичный соединитель. Как описано более подробно далее, первичный соединитель может быть применен, чтобы создавать ссылку службы для мультиплексирования.

Соединители могут быть объявлены всегда, когда могут быть объявлены переменные типа ссылки. Например, соединители могут быть объявлены как локальные переменные, как параметры и/или как поля в VB-модулях или подобным образом. Они могут быть переданы посредством ссылки и скопированы в другие переменные подобно любым объектным ссылкам. В соответствии с аспектом настоящего изобретения ракурс соединителя не может быть когда-либо изменен. А также компилятор может гарантировать это посредством его стабильной типизации. Поэтому в данном аспекте недопустимо использовать «Option Strict Off» (отключение строгого выбора) в любом исходном файле, который определяет или использует соединители или службы вообще.

Сеансы

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

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

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

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

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

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

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

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

В соответствии с иллюстративной VB-оркестрацией все из этого автоматически поддерживается. В одном из аспектов имеет место установленное по умолчанию значение таймаута в 10 минут. Если 10 минут не подходят, можно переконфигурировать таймаут в файле App.config. Это переконфигурирование более подробно обсуждено ниже в отношении «App.config.settings». Когда регламент запущен первоначально, он либо является службой, либо клиентом службы, его сеанс может быть создан до того, как что-либо еще произойдет. Сеанс фактически является экземпляром класса службы. Однако ему также назначен глобальный уникальный идентификатор, который предоставляет клиентам возможность обращаться к нему. Поэтому сеанс также называют экземпляром службы. Очевидно, что последнее может быть чрезвычайно полезным, когда необходимо показать, что ссылаются на отдельный объект в памяти, тогда как предшествующее может быть чрезвычайно полезным, когда желают посмотреть на него с ракурса распределенного приложения.

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

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

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

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

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

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

Регламенты (Оркестрация)

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

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

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

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

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

Службы

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

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

Первое, контракт может быть определен двумя способами: 1) установлением его по имени в операторе принадлежностей; или 2) порождением из тела регламента. Пример первого следует далее.

Service StockQuoteService

Implements CtRequestResponse

End Service

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

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

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

Очевидно, что служба является определением типа, а экземпляр службы является объектом. Однако, поскольку в действительности невозможно сослаться (или смочь использовать ссылку) на экземпляр службы, то иногда трудно понять это взаимоотношение. Службы только взаимодействуют через соединители. Если только обмен сообщениями является единственным путем для взаимодействия со службой, могут они быть перераспределены или скопированы на этом пути, это является необходимым для системы, которая должна поддерживать проекты масштабируемых приложений. Таким образом, службы не могут определять конструкторы или размещаться с использованием выражения «New».

Вторым способом для задания контракта, который реализует служба, является применение компилятора, чтобы извлекать его из кода, включенного в регламент. В этом месте компилятор анализирует код для того, чтобы интерпретировать его. Другими словами, не нужно писать определение контракта. Для использования этого механизма необходимо только объявить сообщения, которые использованы на первичном соединителе. Чтобы быть способным создавать соединители с использованием контракта таких служб, контракт, порожденный для службы, может иметь предсказуемое наименование: например, «<Наименование службы>. Contract».

Service StockQuoteService

In Message Request (Ticker As String) Out Message

Response(Quote As Money)

End Service

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

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

Обмен сообщениями

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

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

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

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

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

Хотя возможно допустить, что второе утверждение противоречит предшествующему обсуждению относительно объявления последовательности операций диалоговой структуры, лучшего, чем реализация в данных, подразумевалось, что разработчик должен быть способным понимать последовательность операций диалога в декларативном виде. Модель рабочего цикла, тем не менее, нуждается в том, чтобы быть моделью, в которой структура диалога представлена в данных. Другими словами, несмотря на то, что «простая» модель подходит в качестве исходного (например, для программиста) вида обработчика протокола, будет принято во внимание, что модель рабочего цикла может быть совершенно разной. Специалист в данной области техники будет принимать во внимание, что в качестве преодоления этого недостатка VB-оркестрация осуществляет управление, чтобы достигнуть высокого уровня увеличения производительности и наглядности.

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

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

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

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

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

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

Отправка и прием сообщений

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

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

Dim qteSrvceConnector As CtRequestResponse=...

Send To qteSrvceConnector Request("MSFT")

Контракт запроса/ответа был описан ранее. Оператор send может иметь соединитель некоторого вида. Соединитель является неявным, если регламент является службой, и send оперирует первичным соединителем. В этом примере клиент соединяется со службой первый раз.

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

На стороне службы, то есть реализующей стороне, сообщение должно быть обработано таким образом:

Receive Request(Ticker As String)

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

Send Response("75.57")

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

Dim Value As String

Receive From qteSrvceConnector Response(Value)

Вышеприведенный пример является представлением завершенного основанного на регламенте приложения. Ниже представлен полный код в одном месте.

Contract CtRequestRespnse

In Message Request (Question As String)

Out Message Response (Answeer As String)

Pattern

Request Then Response → End

End Pattern

End Contract

Service StockQuoteService

Implements CtRequestResponse

Sub Run ()

Receive Request (Ticker AS String)

Send Response(“75.57”)

End Sub

End Service

Public Class StockQuotesRUs

Public Function StockQuoteClient (tcr As String, addr As Uri) AS String

Dim Value As String

Dim gteSrvceConnector As CtRequestResponse=

Ctype (addr, CtRequestResponse)

Send To gteSrvceConnector Request (Ticker)

Receive From gteSrvceConnector Response (Value)

Return Value

End Function

End Class

Очевидно, что посредством добавления выражения «Option Strict On» (например, VB-оркестрация в данный момент требует компиляции в режиме ограничения) в начале файла или посредством добавления некоторого прикладного кода для вызова клиента службы код может быть исполнен без дополнительной конфигурации. Этот код может быть найден в директории «sample-1» («пример-1»).

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

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

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

Чтобы справиться с этими альтернативными ситуациями переходов, VB-оркестрация определяет вариант оператора «select», чтобы обрабатывать прием одного выходящего из множества сообщений.

Select Receive

Case Receive Request(str As String)

...

Case Receive ItsOver1()

...

End Select

В соответствии с этим иллюстративным кодом только одно из двух сообщений «Request» и «ItsOver1» будет принято на этом операторе. Однако, если требуется принять А и В (в любом порядке) или только С, как показано ниже:

State_1:

A And В (State_2

С (State_3

последующий код может выполнить эту задачу:

Select Receive

Case Receive A(), Receive B()

...

Case Receive C()

...

End Select

Точнее, посредством расположения операторов receive на одной и той же линии, например, в одном и том же операторе «Case» в пределах «select Receive» можно указывать, что он будет принимать все сообщения в некотором неопределенном порядке перед продолжением движения. Case для первоочередного выполнения всех его входящих передающих сообщения запросов является тем, который выбран в конечном счете. Поскольку привлечен оператор «select», если С поступает после А, но перед В, то А делается доступным для приема в некоторый другой момент в будущем.

Обращаясь далее к реализации контракта CtRepeatedRequestResponse:

Contract CtRepeatedRequestResponse

In Message Request (Question As String)

Out Message Response (Answer As String)

In Message ItsOver1()

Out Message ItsOver2()

Pattern

Start:

CtRequestResponse→Start

ItsOver1 Or ItsOver2→End

End Pattern

End Contract

Service StockQuoteService

Implements CtRepeatedRequestResponse

Sub Run()

Do

Select Receive

Case Receive Request (Ticker As String)

Send Response (“75.57”)

Case Receive ItsOver1()

Exit Do

End Select

Loop

End Sub

End Service

Public Class StockQuotesRUs

Public Sub GetStockQuotes (addr As Uri)

Dim qteSrvceConnector As CtRepeatedRequestResponse=

Ctype (addr, CtRepeatedRequestResponse)

Dim cmd As String=“”

Console.WriteLine(“Enter ticker symbol: “)

cmd=Console.ReadLine()

While cmd.ToLower<>“quit”

Send To qteSrvceConnector Request (cmd)

Receive From qteSrvceConnector Response (Value As String)

Console.WriteLine(“Quote for “” & cmd & “”:”& Value)

Console.WriteLine(“Enter ticker symbol: “)

cmd=Console.ReadLine()

End While

Send To qteSrvceConnector ItsOver1()

End Sub

End Class

Существуют несколько аспектов, которые заслуживают внимания в этом месте. Первый, оператор «select Receive» показан в действии, но он также вложен в обычный оператор цикла «Do». Существует очень немного ограничений в отношении включений регламента (например, дальше обсуждены «Языковые ограничения»), циклов нет среди них. В клиенте службы цикл использован вокруг операторов send/receive, которые были взаимодействиями системы с пользователем, которому позволено запрашивать назначение цены товара снова и снова. Этот код имеется в распоряжении среди DVS-примеров как Sample-2.

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

В этом месте клиент службы также может использовать оператор «select Receive», чтобы иметь дело с этой возможностью.

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

Точнее, интервал таймаута может быть помещен в оператор «select Receive», и чтобы получить лучшее управление ситуацией, когда сообщение не приходит.

Service StockQuoteService

Implements CtRepeatedRequestResponse

Sub Run()

Do

Select Receive Within TimeSpan.FromMinutes(1)

Case Receive Request (Ticker As String)

Send Response(“75.57”)

Case Receive ItsOver1()

Exit Do

Case TimeOut:

Send ItsOver2()

Exit Do

End Select

Loop

End Sub

End Service.

Тип интервала может быть System.TimeSpan. Вызов метода «FromMinutes», приведенный выше, является одним из разделяемых методов на этом типе, который предоставляет возможность TimeSpan быть сформированным из конкретных единиц времени (например, секунд, минут, часов). Обратитесь к документации оболочки.NET для больших подробностей о System.TimeSpan.

Определение оператора «select Receive» таково, что, если TimeSpan равен 0, то включение таймаута будет употреблено, если включение не может быть незамедлительно удовлетворено сообщениями, которые уже поступили и ожидают. Другими словами, это способ удостовериться, что оператор выборочного приема не приостанавливается. Это предоставляет регламенту возможность делать быструю проверку некоторых сообщений, которые, если они доступны, должны быть обработаны незамедлительно; если нет, то существуют более подходящие дела для выполнения регламентом.

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

Расщепленные линии

Несмотря на то, что «select Receive» был обоснованным для поддержки вариантов выбора и групп неупорядоченных сообщений, которые инициируют одиночный переход состояния, он неудобен при поддержке расщеплений в контракте. В этом примере допустим, что шаблон контракта - это:

State_1:

A (State_2, State_3

State_2:

В (State_4

State_3:

С (State_4

На принимающей стороне это может быть закодировано таким образом:

Dim gotA As Boolean=False

Dim gotB As Boolean=False

Dim gotC As Boolean=False

While Not gotA AndAlso Not gotB AndAlso Not gotC

Select Receive

Case Receive A()

When Not gotA

"Handle A

gotA=True

Case Receive B()

When Not gotB

"Handle В

gotB=True

Case Receive C()

When Not gotC

“Handle С

gotC=True

End Select

End While

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

Split

Line

Receive A()

“Handle A

Line

Receive B()

"Handle В

Line

Receive C()

"Handle С

End Split

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

Оператор «split» может обеспечивать VB-оркестрацию параллелизмом, не требующим озабоченности сложностями совместного исполнения. Вышеприведенное высказывание означает то, что три включенных блока в пределах «split», называемые расщепленными линиями, могут исполняться независимо друг от друга, например параллельно.

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

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

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

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

Public Class StockQuotesRUs

Public Sub GetStockQuotes(addr As Uri)

Dim qteSrvceConnector As CtRepeatedRequestResponse=…

Dim value As String

Split

Line

Dim cmd As String=“”

Console.WriteLine(“Enter ticker symbol: ”)

cmd=Console.ReadLine()

While cmd.ToLower<>“quit”

Send To qteSrvceConnector Request(cmd)

Receive From qteSrvceConnector Response (Value)

Console.WriteLine(“Quote for “” & cmd & “”: “& value)

Console.WriteLine(“Enter ticker symbol: ”)

cmd=Console.ReadLine()

End While

Send To qteSrvceConnector ItsOver1()

Exit Split

Line

Receive From qteSrvceConnector ItsOver2()

Exit Split

End Split

End Sub

End Class

заметим, что первая расщепленная линия идентична предварительно описанной реализации. Заметим, что все, что сделано, это то, что добавлен «Exit Split». Это еще один вариант общепринятого оператора «Exit», который завершает все расщепленные линии ближайшего оператора «Split». Вторая расщепленная линия ожидает сообщения «ItsOver2», которое может никогда не прибыть. Если это не так, то первая линия будет завершать оператор.

Классы оркестрации

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

Public Class StockQuotesRUs

Public Sub GetStockQuote(addr As Uri)

Dim qteSrvceConnector As CtRepeatedRequestResponse=…

Dim value As String

Split

Line

Dim cmd As String=“”

Console.WriteLine(“Enter ticker symbol: ”)

cmd=Console.ReadLine()

While cmd.ToLower<>“quit”

Send To qteSrvceConnector Request(cmd)

Receive From qteSrvceConnector Response (Value)

Console.WriteLine(“Quote for “” & cmd & “”: “& value)

Console.WriteLine(“Enter ticker symbol: ”)

cmd=Console.ReadLine()

End While

Send To qteSrvceConnector ItsOver1()

Exit Split

Line

Receive From qteSrvceConnector ItsOver2()

Exit Split

End Split

End Sub

Public Function GetStockQuote(addr As Uri, ticker As String) As String

Dim qteSrvceConnector As CtRepeatedRequestResponse=…

Send To qteSrvceConnector Request(ticker)

Receive From qteSrvceConnector Response (Value As String)

Send To qteSrvceConnector ItsOver1()

Return Value

End Function

End Class

Можно расчленить его таким образом:

Public Class StockQuotesRUs

Public Sub GetStockQuote(addr As Uri)

Dim qteSrvceConnector As CtRepeatedRequestResponse=…

Dim value As String

Split

Line

Dim cmd As String=“”

Console.WriteLine(“Enter ticker symbol: ”)

cmd=Console.ReadLine()

While cmd.ToLower<>“quit”

Value=GetSingle(qteSrvceConnector, cmd)

Console.WriteLine(“Quote for “” & cmd & “”: “& value)

Console.WriteLine(“Enter ticker symbol: ”)

cmd=Console.ReadLine()

End While

Send To qteSrvceConnector ItsOver1()

Exit Split

Line

Receive From qteSrvceConnector ItsOver2()

Exit Split

End Split

End Sub

Public Function GetStockQuote(addr As Uri, ticker As String) As String

Dim qteSrvceConnector AS CtRepeatedRequestResponse=…

Dim value As String=GetSingle(qteSrvceConnector, ticker)

Send To qteSrvceConnector ItsOver1()

Return Value

End Function

Private Function GetSingle(ctor As CtRepeatedRequestResponse, ticker AS String) AS String

Send To ctor Request(ticker)

Receive From ctor Response (value As String)

Return Value

End Function

End Class

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

Путем простой замены объявления класса на:

Public Orchestration Class StockQuotesRUs

желаемое поведение может быть достигнуто. Другими словами, оператор Receive в начале GetSingle означает, что расщепленная строчка дает результат, и вторая строчка может исполняться.

Ожидание

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

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

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

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

В последней ситуации служба наблюдения может использовать «select Receive» и устанавливать интервал таймаута в некоторое значение, немного большее, чем согласованный интервал. Если сигнал работоспособности поступает, то никаких проблем не возникает, но если предписание просрочено, то это является показателем того, что что-то плохое имеет место, и служба наблюдения должна отправить некоторый вид сигнала тревоги.

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

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

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

Поэтому важно в модели принимать в расчет необходимость в задержке. Это делается при помощи оператора «Wait»:

Wait TimeSpan.FromMinutes(1)

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

Service Client MonitorServiceAt (serviceRef As Uri)

Schedule

Dim monitoredService As=HeartBeat(serviceRef)

Dim period As TimeSpan=TimeSpan.FromSeconds(30)

Do

Dim before As DateTime=DateTime.Now

Send monitoredService AreYouAlive()

Receive From monitoredService Pulse()

Wait (before+period - DateTime.Now)

Loop

End Schedule

End Service

Заметим, что система может компенсировать время, которое она берет для исполнения тела цикла. Это должно дать гарантию, что период ожидания так близок к указанному времени, как это возможно.

Операндом оператора Wait может быть операнд типа System.TimeSpan.

Динамический параллелизм

Несмотря на то, что оператор Split может предоставлять телу кода возможность давать определения, нет способа использовать его для исполнения параллельно n линий кода. Случай для такого динамического поведения значителен и поддерживается двумя разными способами.

1. Операторами Split-For-Each,

2. Операторами Split-Select-Receive.

Первый имеет ту же основную семантику, как и оператор For-Each, за исключением того, что он выполняет каждую итерацию цикла параллельно со всеми другими операциями. Другими словами, есть столько параллельных линий исполнения, сколько есть пунктов в наборе, который итеративно выполняют. Как только это количество определено, дополнительные линии не могут быть добавлены в параллельный оператор. Split-For-Each содержит то же правило «объединения», что и Split: когда все итерации завершены, завершен и Split-For-Each оператор.

В качестве примера:

Split For Each itm As SKU In skuList

Dim warehouse As Warehouselnventory=...

Send To warehouse Allocate(itm)

Receive From warehouse Confirmation

Next

Преимущество этого над нормальным For-Each, содержащим такие операторы, в том, что все операторы Receive ожидают параллельно. Чем больше задержка между отправкой и приемом, тем становится более важным быть способным это делать.

«Split-Select-Receive» может быть использован, чтобы динамически запускать новые линии параллельного исполнения в ответ на приходящие сообщения. Один из вариантов зависит от нашего понимания мультиплексных диалогов, но более простым вариантом является вариант, который помогает нам реализовать такой контракт (A, B и C - все входящие сообщения):

S1:

A (S1 And S2

С (S3

S2:

В (S3

S3:

Здесь контракт предоставляет возможность принимать любое количество чередующихся последовательностей<A, B>до получения С, при котором он ожидает все B, которые должны прийти. Можно получить жесткое время реализации этого, используя оператор Select-Receive в цикле, поскольку каждая последовательность<A, B>обрабатывается независимо от всех других. Можно, однако, использовать Split-Select-Receive:

Split Select Receive

Case Receive A()

Receive B()

Case Receive C()

Finish Split

End Select

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

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

Выход

Некоторые из новых вариантов «Exit» уже были продемонстрированы выше, но для облегчения понимания повторение того, что они из себя представляют и что они делают, предоставлено ниже:

Exit Split

Это будет завершать все выдающие результат линии из расположенных вблизи «split», «split-For-Each» или «split-Select-Receive» и переходить на соответствующий оператор «End» или «Next».

Exit Line

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

Фильтры

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

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

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

Select Receive

Case Receive A(s1 As String) When s1="ACK", B(s2 As String)

" Handle situation

Case Receive A(s3 As String) When s3="OK"

" Handle situation

End Select

Этот оператор будет согласовывать сообщение A только если параметр сообщения имеет значение «OK», иначе он будет принимать A и B, если параметр сообщения А имеет значение «ACK». Если ни одна из этих ситуаций не верна, то оператор ожидает до тех пор, пока это не произойдет. Фильтр может таким образом быть вызван много раз до того, как сообщение согласовано, таким образом, крайне необходимо, чтобы это было правильное выражение без побочных эффектов.

Вторичные соединители

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

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

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

А что если служба желает предоставить другим клиентам возможность инициировать диалог с ней либо по тому же самому контракту, как и первичный соединитель, либо некоторому другому? Первичный соединитель уже не свободен, следовательно, совместное его использование - это не выбор. Кроме того, если хочется реализовать некий другой контракт, так или иначе первичный соединитель, вероятно, бесполезен.

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

Создание нового, вторичного реализующего соединителя, проиллюстрировано далее:

Dim SecondaryConnector As Implements RequestResponse=CtRequestResponse().

Следует обратить внимание на две вещи:

1. Можно использовать ключевое слово «Implements» в качестве модификатора типа в объявлении переменной. Это дает объявляемой переменной реализующий ракурс.

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

Модификатор «Implements» типа соединителя может быть использован в любом месте, где может создаваться переменная соединителя, в том числе в качестве класса или элемента модуля или в качестве параметра для метода. Попытка назначить объект одного ракурса для переменной противоположного ракурса может претерпевать неудачу во время компиляции. Заметим, что правило для назначения переменной соединителя может быть прямо противоположным правилу для связывания соединителя с соединителем. Другими словами, соединители могут быть назначены только соединителями того же ракурса, но они должны быть связаны с соединителем противоположного ракурса.

Служба не обнаружена

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

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

Взамен проблема решается подменой метода в классах оркестрации:

Protected Overrides Sub OtherSideNotThere(ByVal sref As String)

...

End Sub

Таймауты

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

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

Есть две ситуации, которые требуют отдельной обработки:

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

2. Если заданное сообщение не прибывает, регламент может прийти в себя от этого и продолжаться с информацией, установленной по умолчанию, или попытаться повторно отправить запрос, или связаться с некой другой службой по поводу информации. Операторы Select/Receive с интервалами таймаутов рекомендованы для этой ситуации. Эти ситуации были обсуждены ранее:

Select Receive Within TimeSpan.FromMinutes{10)

Case Receive Response(str As String)

Case TimeOut:

End Select.

Отметим, что, как продемонстрировано выше, операторы Select/Receive не обязаны иметь многочисленные case. Оператор Receive является фактически более рационально реализованной (но функционально эквивалентной) версией Select/Receive с единственным case. Другими словами,

Receive A (...)

эквивалентен по отношению к:

Select Receive

Case Receive A (...)

End Select

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

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

- ждать чуть дольше;

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

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

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

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

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

Select Receive Within TimeSpan.FromMilliseconds(100)

Case Receive From Connector_1 Response(str As String)

Case TimeOut:

Connector_1.Di scard()

End Select

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

Заметим, что интервалы таймаута в операторах select не устанавливают верхний предел для полного времени, которое группа операторов отнимает на выполнение, а только время, которое один оператор ожидает сообщения. Чтобы сделать первое, можно применить операторы split и wait:

Split

Line

Wait TimeSpan.FromMinutes{2)

Exit Split

Line

" Some timed activity of multiple statements.

End Split

Поскольку VB-оркестрация не предъявляет требований поведения реального времени, отсутствует гарантия, что это не будет отнимать больше чем две минуты, которые были назначены. Только когда вторая линия достигает события приостановки, оператор split на самом деле заканчивается, и выполняется оператор, следующий за «End Split».

Взаимодействие с нерегламентным кодом

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

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

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

Каждое сообщение в контракте имеет результатом события, являющиеся добавляемыми к типу. Поскольку методы и события не могут быть перегружены в.NET, наименованием события является наименование сообщения со строкой «Event», непосредственно конкатенированной к нему. Метод имеет точно такое же наименование, как и сообщение. В качестве примера:

Private Sub Foo()

Dim Connector_l As CtRequestResponse=...

AddHandler Connector_l.ResponseEvent, AddressOf

ResponseHandler

Send To Connector_1 Request ("Gimme!")

...

End Sub

Private Sub ResponseHandler(str As String)

...

End Sub

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

Графические интерфейсы пользователя

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

Эта особенность легка для использования, но должна ограничиваться ситуациями, где она реально требуется. Будет принято во внимание, что принудительное применение кода регламента к одиночному потоку будет ограничивать возможность для совместного исполнения и поэтому является потенциальным препятствием выполнения.

Dim connector As Contract_1=...

Connector.SetControl(Porral)

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

Primary.SetControl(Form1)

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

Последующее является примером при использовании «setControl()» («установить контроль»):

Select Receive

Case Receive From connectorl A(), Receive From connector2 B()

End Select

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

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

Рабочая вычислительная среда

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

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

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

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

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

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

Со ссылкой на фиг.7 проиллюстрирована примерная среда 700 для реализации различных аспектов изобретения, которая включает в себя компьютер 702, устройство 704 обработки данных, системную память 706 и системную шину 708. Системная шина 708 соединяет компоненты системы, включая, но не в качестве ограничения, системную память 706 с устройством 704 обработки данных. Устройство 704 обработки данных может быть любым из различных доступных для приобретения процессоров. Сдвоенные микропроцессоры и другие многопроцессорные архитектуры также могут быть применены в качестве устройства 704 обработки данных.

Системная шина 708 может быть любой из некоторых шинных структур, которые могут дополнительно взаимно связываться с шиной памяти (с помощью или без контроллера памяти), периферийной шиной и локальной шиной, используя любые из многообразия доступных для приобретения шинных архитектур. Системная память 706 включает в себя постоянное запоминающее устройство 710 (ROM, ПЗУ) и оперативное запоминающее устройство 712 (RAM, ОЗУ). Базовая система ввода/вывода (BIOS) сохранена в энергонезависимой памяти 710, такой как ПЗУ, EPROM (СППЗУ - стираемое программируемое постоянное запоминающее устройство), чей BIOS содержит базовые процедуры, которые содействуют передаче информации между элементами в пределах компьютера 702, к примеру во время запуска. ОЗУ 712 может также включать в себя высокоскоростное ОЗУ, такое как статическое ОЗУ для кэширования данных.

Компьютер 702 дополнительно включает в себя внутренний накопитель 714 на жестком диске (HDD) (например, с EIDE -усовершенствованной электронной схемой управления встроенным дисководом, SATA - последовательной продвинутой технологией подключения), чей внутренний накопитель 714 на жестком диске может также быть сконфигурирован для внешнего использования в подходящем аппаратном блоке (не показан), накопитель 716 на гибких магнитных дисках (FDD) (например, для считывания или записи съемной дискеты 718) и накопитель 720 на оптических дисках (например, считывающий диск 722 CD-ROM, или для считывания или записи других оптических носителей большой емкости, таких как DVD). Накопитель 714 на жестком диске, накопитель 716 на магнитных дисках и накопитель 720 на оптических дисках могут быть присоединены к системной шине 708 посредством, соответственно, интерфейса 724 накопителя на жестком диске, интерфейса 726 накопителя на магнитных дисках и интерфейса 728 оптического накопителя. Интерфейс 724 для внешней реализации накопителя включает в себя по меньшей мере одну или обе интерфейсные технологии универсальной последовательной шины (USB) и IEEE 1394 (института инженеров по электротехнике и радиоэлектронике).

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

Некоторое количество программных модулей может быть сохранено в накопителях и ОЗУ 712, включая операционную систему 730, одну или более прикладных программ 732, другие программные модули и программные данные 736. Все или часть из операционной системы, приложений, модулей и/или данных могут также быть буферизированы (кэшированы) в ОЗУ 712.

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

Пользователь может вводить команды и информацию в компьютер 712 через одно или более проводных/беспроводных устройств ввода, например, клавиатуру 738 и координатно-указательное устройство, такое как мышь 740. Другие устройства ввода (не показаны) могут включать в себя микрофон, пульт дистанционного управления, джойстик, игровую панель, перо, сенсорный экран или подобное. Эти и другие устройства ввода часто присоединены к устройству 704 обработки данных через интерфейс 742 устройств ввода, который соединен с системной шиной 708, но могут быть присоединены посредством других интерфейсов, таких как параллельный порт, последовательный порт стандарта IEEE 1394, игровой порт, USB-порт, интерфейс ввода/вывода (I/O) и т.п.

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

Компьютер 702 может работать в среде с сетевой структурой, использующей соединения через проводные и/или беспроводные средства связи с одним или более компьютерами, такими как удаленные компьютеры 748. Удаленные компьютеры 748 могут быть рабочей станцией, серверным компьютером, персональным компьютером, переносным компьютером, основанным на микропроцессоре игровым аппаратом, одноранговым устройством или другим обычным сетевым узлом и типично включают в себя многие или все элементы, описанные касательно компьютера 702, хотя в целях краткости проиллюстрировано только запоминающее устройство 750 памяти. Изображенные логические соединения включают в себя средства проводного или беспроводного соединения с локальной сетью 752 (LAN) и/или более крупные сети, такие как глобальная сеть 754 (WAN). Такие сетевые среды LAN и WAN являются обычными в офисах и компаниях и содействуют компьютерным корпоративным сетям, таким как сети интранет (локальные сети, применяющие технологии Интернет), все из которых могут соединяться с глобальной сетью передачи данных, например, Интернетом.

При использовании в сетевой среде LAN компьютер 702 присоединен к локальной сети 752 через проводной и/или беспроводной сетевой интерфейс передачи данных или адаптер 756. Адаптер 756 может способствовать проводной или беспроводной связи с LAN 752, которая также может включать в себя беспроводную точку доступа, расположенную в ней для поддержания связи с беспроводным адаптером 756. При использовании в сетевой среде WAN компьютер 702 может включать в себя модем 758, или быть подключен к серверу связи в LAN, или имеет другое средство для установления связи через WAN 754, например, для достижения Интернета. Модем 758, который может быть внутренним или внешним и проводным или беспроводным устройством, присоединен к системной шине 708 через интерфейс 742 последовательного порта. В сетевой среде программные модули, изображенные касательно компьютера 702, или их части могут быть сохранены в удаленной памяти/запоминающем устройстве 750. Будет принято во внимание, что показанные сетевые соединения являются иллюстративными, и другое средство установления канала связи между компьютерами может быть использовано.

Компьютер 702 работоспособен при связи с любыми беспроводными устройствами или сущностями, с возможностью работы распределенные по беспроводной связи, например, принтер, сканер, настольный и/или переносной компьютер, портативное вспомогательное цифровое устройство, спутник связи, любые части оборудования или участки, ассоциативно связанные беспроводным образом обнаруживаемым признаком (например, киоск, новостной стенд, комната отдыха) и телефон. Это включает в себя по меньшей мере технологии Wi-Fi (беспроводную сеть стандарта IEEE 802.11-1999) и Bluetooth™ (универсальную технологию беспроводной связи разнотипных микропроцессорных устройств локальной сети). Таким образом, система связи может быть предопределенной структурой как в примере с традиционной сетью или просто специально подобранной связью между по меньшей мере двумя устройствами.

Wi-Fi (Wireless Fidelity) предоставляет возможность присоединения к Интернету с домашнего дивана, гостиничной койки или конференц-зала на работе, не используя провода. Wi-Fi является беспроводной технологией, подобной сотовому телефону, которая позволяет таким устройствам, например компьютерам, отправлять и принимать данные внутри помещения и вне его, где угодно в пределах радиуса действия базовой станции. Сети Wi-Fi используют радиотехнологии, называемые IEEE 802.11 (a, b, g и т.д.), чтобы обеспечивать безопасную, надежную, быструю беспроводную способность к взаимодействию. Сеть Wi-Fi может быть использована для соединения компьютеров друг с другом, с Интернетом и с проводными сетями (которые используют IEEE 802.3 или Ethernet). Сети Wi-Fi работают в нелицензируемых радиодиапазонах 2, 4 и 5 ГГц со скоростью передачи данных в 11 МБод (802.111 b) или 54 МБод (802.111 a) или с изделиями, которые содержат оба диапазона (двухдиапазонными), так что сети могут обеспечивать реальную производительность, подобную базовым 10BaseT проводным сетям Ethernet, используемым во многих офисах.

Ссылаясь далее на фиг.8, проиллюстрирована схематичная структурная диаграмма иллюстративной вычислительной среды 800 в соответствии с настоящим изобретением. Система 800 включает в себя одного или более клиентов 802. Клиент(ы) 802 может быть аппаратным средством или программным обеспечением (например, потоками, процессами, вычислительными устройствами). Клиент(ы) 802 может вмещать в себя, например, фрагмент(ы) данных о предыстории и/или ассоциативно связанную контекстную информацию посредством применения настоящего изобретения. Система 800 также включает в себя один или более серверов 804. Сервер(ы) 804 также может быть аппаратным средством и/или программным обеспечением (например, потоками, процессами, вычислительными устройствами). Серверы 804, например, могут вмещать потоки для выполнения преобразований с применением настоящего изобретения. Одна из возможных связей между клиентом 802 и сервером 804 может быть в виде пакета данных, адаптированного для передачи между двумя или более вычислительными процессами. Пакет данных, например, может включать в себя фрагмент данных о предыстории пользователя и/или ассоциативно связанную контекстную информацию. Система 800 включает в себя структуру 806 связи (например, глобальную сеть передачи данных, такую как Интернет), которая может быть применена для содействия передаче данных между клиентом(ами) 802 и сервером(ами) 804.

Обмен данными может быть облегчен посредством проводной (включая оптическое волокно) и/или беспроводной технологии. Клиент(ы) 802 с возможностью работы присоединены к одному или нескольким хранилищам 808 данных клиента, которые могут быть применены для хранения информации, локальной для клиента 802 (например, фрагмент(ы) данных о предыстории обращений и/или ассоциативно связанную контекстную информацию). Подобным образом сервер(ы) 804 с возможностью работы присоединены к одному или более хранилищам 810 данных сервера, которые могут быть применены для хранения информации, локальной для серверов 804.

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

То, что было описано выше, включает в себя примеры настоящего изобретения.

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

ПРИЛОЖЕНИЕ А

Беступиковое соответствие

Чедрик Фурне, Тони Хоаре, Шрирам К.Раджамани, Джакоб Рехов

Исследовательская работа корпорации Майкрософт

{fournet, thoare, sriram, rehof }@microsoft.com

Реферат. Мы представляем новое усовершенствованное отношение (беступиковое соответствие) для CCS-процессов (CCS - Calculus of Communicating System - исчисление обменивающихся данными систем), которое удовлетворяет свойству заместимости. Если I соответствует S, а P - любая среда, такая что P|S беступиковый, то P|I беступиковый. Беступиковость имеет отношение к понятию зависания в CSP (Communicating Sequential Processes - Обменивающихся данными последовательных процессах), но она более избирательна из-за того, что принимает к учету зависшие сообщения. Мы утверждаем, что соответствие является преконгруэнтностью на CSS-процессах, таким образом, поддерживая модульную детализацию. Мы находим различие соответствия от имеющих отношение отличительных признаков, детализации устойчивых отказов в CSP и отличительного признака непринятия в CCS. Мы реализовали проверку соответствия в новом средстве проверки модели программного обеспечения, ZING, и мы предоставляем отчет о том, как мы использовали его для нахождения ошибок в распределенных программах.

1. Введение

Мы заинтересованы в проверке того, что передающие сообщения программы являются беступиковыми [11]. Беступиковость формализует свойство, при котором обменивающаяся данными система не может зависать, ожидая сообщений, которые никогда не отправляются, или отправлять сообщения, которые никогда не принимаются. В этом документе мы расширяем [11] обобщением теории соответствия и отчетом о его применении в модели, проверяющей распределенные программы. В нашем применении примера программисты пишут контракты, которые являются интерфейсами, которые задают внешне наблюдаемое поведение программ по передаче сообщений. Контракты могут быть настолько наполнены возможностями, насколько и CCS-процессы. Беступиковость гарантируется проверкой того, что реализация соответствует ее контракту, с использованием средства проверки модели.

Проверка беступиковости посредством исследования пространства состояний всей системы быстро ведет к интенсивному росту числа состояний, поскольку пространство состояний растет экспоненциально с количеством совместно исполняющихся процессов; и это требует, чтобы вся система была доступна для анализа, что особенно нереалистично для распределенных систем. Мы поэтому желаем проверять беступиковость композиционно. Если I является реализацией компонента, C является его контрактом, мы используем запись I (С для обозначения того, что I соответствует C. Для нашего композиционного подхода, который должен быть озвучен касательно беступиковости, отношение (соответствие необходимо, чтобы удовлетворять следующему свойству заместимости: если I (С и P - любое окружение, такое что P | С является беступиковым, то P | I также беступиковая (P | С обозначает параллельную композицию P и С). Заместимость означает, что контракт компонента может быть благополучно использован вместо компонента в контекстах вызова, и поэтому она содействует проверке модели на масштабируемость.

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

Этот документ предлагает следующие результаты.

- Мы даем определение понятию соответствия, основываясь на стандартной семантике CCS-перехода, и доказываем, что оно является преконгруэнтностью (то есть оно сохраняется всеми CCS-контекстами), удовлетворяющей свойству заместимости для беступиковости. Мы определяем соответствие из имеющих наиболее близкое отношение известных отличительных признаков, детализации [3, 5, 12] устойчивых отказов CSP и отличительного CCS-признака [10] непринятия.

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

Этот документ значительно расширяет работу, опубликованную в [11], которая вносит отношение соответствия, удовлетворяющее свойству заместимости. Отношение соответствия по [11] ограничено в некоторых аспектах. Во-первых, соответствие в [11] определено посредством ссылки на синтаксическую форму процессов¹ (¹например, некоторые положения в определении соответствия по [11] применяются только к процессам вида P#Q или P+Q; другие подобные синтаксические зависимости этой природы также представлены в [11]), которая препятствует точно соблюдаемой реализации проверки соответствия, из-за записи действий, вырабатываемых переходами. Во-вторых, отношение в [11] не является преконгруэнтностью, поскольку синтаксические ограничения не соблюдены при произвольных CCS-контекстах. Как следствие, естественные и полезные алгебраические законы не исполняются, включая желательный модульный принцип, по которому P ₁ (Q ₁ и P ₂ (Q ₂ подразумевает, что P ₁|P ₂ (Q ₁|Q ₂. В-третьих, теория в [11] сложна для понимания из-за использования нестандартных действий² (²действие поименовано (в [11]) для обработки неопределенности. Этот документ предусматривает значительное обобщение соответствия, которое безукоризненно соблюдено, основано на стандартной системе CCS-переходов, и предоставляет унифицированную интерпретацию неопределенности, сокрытия и стабильности в исчислении сокрытых действий (τ). Оно может быть реализовано в средстве проверки модели посредством экспериментального обнаружения видимых действий и стабильности, и его можно сопоставить отношениям детализации другой семантики. В дополнение к доказательству заместимости мы доказываем, что наше обобщенное отношение соответствия является преконгруэнтностью, таким образом поддерживая модульную детализацию. В заключение, мы применили эту теорию посредством реализации ее в средстве проверки модели программного обеспечения и применения его к проверке контракта для распределенных программ.

Оставшаяся часть этого документа организована, как изложено ниже. В разделе 2 мы обсуждаем отношения детализации в традициях CSP и CCS, которые наиболее тесно связаны с беступиковым соответствием. В разделе 3 мы представляем нашу теорию соответствия. Для того чтобы сохранить документ в пределах ограничений, мы опустили все доказательства в представлении нашей теории соответствия. Абсолютно подробные доказательства могут быть найдены в нашем техническом отчете [?]. В разделе 4 мы описываем применение средства проверки соответствия ZING для обнаружения ошибок в распределенных программах, и раздел 5 делает вывод.

2. Родственная работа

Наше понятие соответствия промоделировано в детализации устойчивых отказов в CSP [3, 5, 12] и вдохновлено успехом средства проверки FDR [12] детализации. Наша модель процесса сочетает рабочую семантику CCS с понятием непринятий, подобным, но отличным от понятия в CSP. Определение соответствия полагается на симуляцию и применяется непосредственно к любой системе помеченных переходов, в которой могут быть соблюдены видимые действия и стабильность. Как обсуждено в разделе 3.3, заместимость касательно беступиковости не удовлетворена, если детализация устойчивых отказов перенимается непосредственно для CCS. Причина состоит в том, что беступиковость - другое и более избирательное понятие в сравнении с CSP-представлением зависания. Для того чтобы нивелировать это различие, наше отношение соответствия основано на идее подготовленных непринятий, которая требует от процесса быть готовым согласовать определенные действия, при этом (в то же время) осуществляя непринятие других.

Беступиковое соответствие также имеет отношение к отличительному признаку непринятий для CCS, который был разработан в теории тестирования [10] непринятия Иэйна Филлипса. Отличительный признак непринятия предоставляет возможность обнаружения действий, которые происходят после непринятий и могут поэтому выражать условия готовности в сочетании с непринятиями. Однако, как обсуждено в разделе 3.4, беступиковое соответствие является строго большей преконгруэнтностью в сравнении с отличительным признаком непринятия.

Понятие 2/3-бисимуляции, представленное Ларсеном и Скоу [6], несет некоторое сходство с соответствием. Однако Ларсен и Скоу не рассматривают сокрытие и внутренние действия (τ-действия), и поэтому проблемы стабильности там не проявляются. Наша теория соответствия предоставляет унифицированный способ обращения с внутренними действиями, неопределенностью и стабильностью, которые являются существенными в наших применениях. Альтернативная симуляция [1] была использована, чтобы установить взаимосвязь интерфейсов с реализациями в [4]. Как обсуждено в [11], альтернативная симуляция не удовлетворяет заместимости для беступиковости.

3. Теория соответствия

В этом разделе мы даем необходимые основы по CCS [7, 8], мы определяем наши понятия беступиковости и соответствия, и мы доказываем, что соответствие является преконгруэнтостью (теорема 1) и что оно удовлетворяет свойству заместимости (теорема 2).

3.1. CCS-процессы

Мы принимаем счетное множество имен . Множество названо множеством меток. Множество названо множеством действий. Мы допускаем, что (покрывает A и допускаем, что (покрывает L, и мы записываем . Для подмножества X из L мы записываем . CCS-процессы, покрываемые P, определены как:

P::=0|A a₁,... a_n | G ₁ +...+G _n|(P|Q)|((a)P

G::=α.P

Здесь A покрывает имена процессов вместе с определением равенств . Мы говорим, что a является связанным в ((a)P. Свободными имена процесса P, обозначенными fn(P), являются имена в P, которые не связаны.

Определение 1 (Структурная конгруэнтность, ≡) Структурной конгруэнтностью ≡, является наименьшее отношение конгруэнтности, удовлетворяющей условиям, заключенным в следующих правилах, вместе с заменой связанных имен и переменных (альфа-конверсией) и переупорядочиванием элементов в суммировании:

1. P|0 (P, P|Q (Q|P, P|(Q|R) ((P|Q)|R

2. ((a)P|Q (P, P|Q (P|((a)Q, если a (fn(P)

3. ((a)0 (0 , ((ab)P (((ba)P, ((a)((b)P (((b)((a)P

Рабочая семантика CCS задана посредством системы помеченных переходов, показанных в определении 2. Эта система в точности является системой, заданной Милнером [8], за исключением того, что мы дополнили правило [CONG], которое является стандартным в последних представлениях CCS. В правиле [SUM] M покрывает суммирование.

Определение 2 (Помеченный переход)

Мы допускаем, что . Различие между и существенно. Первое представляет внутреннюю цепочку, в которой процесс делает выбор, чтобы перейти на a.P или b.Q, тогда как последнее представляет внешнюю цепочку [5], где окружение управляет тем, переходит ли процесс к P или Q, предлагая или . Различие между внутренней и внешней цепочкой является ключевым в нашем понятии соответствия.

Асинхронные действия моделируются как действия с отсутствием последовательного продолжения в CCS. Следовательно, асинхронные действия «порождаются», как в a | P, где a происходит асинхронно.

Условное обозначение. Мы зписываем и для (возможно пустых) последовательностей имен и действий. Для мы записываем если существуют P ₀,P ₁,...P _n, такие что P (P ₀, P' (P _n, и, для 0 (i (n, мы имеем Мы используем условное обозначение где (τ ^* λ) ({λ, τλ, ττλ,...}. Мы записываем если существует , такое, что означает, что существует P', такое что означает, что для некоторого . P стабилен, если P не производит скрытых действий, то есть и P является конечным состоянием, если P не производит никаких действий совсем, то есть В заключение мы используем краткое условное обозначение для обозначения того, что (или из числа меток, появляющихся в .

3.2. Беступиковость, подготовленное отклонение и соответствие

Если два процесса P и Q обмениваются данными через локальные имена в , мы можем записать систему как . Поскольку - локальные имена для P и Q, то больше нет окружения, которое может взаимодействовать по , и следовательно, оно создает обоснованность для проверки, полностью ли удается взаимодействие P и Q по . Неформально мы объявляем тупик процесса в , если он не производит никакого продвижения, и некоторая его часть готова для обмена данным и по имени в : обмен данными по не удался потому, что он не закончился. В наших применениях P типично является моделью программы, которая имеет локальное присоединение к процессу, чьей спецификацией (контрактом) является Q. Мы желаем проверить, что взаимодействие между P и реализацией, представленной посредством Q, является беступиковым, то есть оно не может зайти в тупик. Беступиковость является показателем надежности и может быть проверена посредством анализа достижимости системы P|Q. Последующие определения делают понятия тупиковости и беступиковости строгими.

Определение 3. (Тупиковый процесс). Процесс P называется тупиковым на , если является конечным состоянием, и для некоторого . Мы упоминаем такое (в качестве оставшегося действия.

Определение 4. (Беступиковый процесс). Процесс P называется беступиковым на , если не существует P' и , таких что при , и P' тупиковом на .

В ситуации, упомянутой выше, мы применяем определение 4 посредством поиска перехода такого что и P'|Q' тупиковый на . Ограничение в определении 3 и условие в определении 4 настаивают на том, чтобы только внутренние действия (τ-действия) могли происходить по именам в , сообразно с , являющимся локальным. Поскольку для некоторого , взаимодействие между P и Q заканчивается остаточным действием λ, которое не может быть согласовано каким-либо совместным действием . Если (моделирует действие ввода, то компонент ожидает приема сообщения, которое никогда не поступает, а если (моделирует действие отправки, то компонент отправляет сообщение, которое никогда не поглощается. Примером последнего является действующее на расстоянии сообщение исключения, которое не обрабатывается. Такие ситуации являются важными показателями проблем во многих асинхронных приложениях. Раздел 4 содержит примеры того, как мы применили определение 4 при проверке соответствия действующих систем.

Мы добиваемся отношения соответствия ≤, такого что S (Q гарантирует свойство заместимости, при котором, если P|Q является беступиковым, то и P|S является беступиковым на любых отобранных именах . В примерном сценарии это означает, что он безопасен для проверки беступиковости системы P|Q, в которой реализация S представлена ее контрактом Q. Чтобы достичь этой цели, отношение (должно быть таким, что, если S (Q, то Q становится в тупик на в любом контексте по меньшей мере так же часто, как S. Это требование подразумевает, что Q не может обещать предоставлять действия, которые в действительности не доставлены посредством S и могут быть элегантно зафиксированы понятием отказа в CSP [5]. Однако это исключено тем, что необходимое условие непринятия само по себе недостаточно, поскольку оно не исключает все случаи остаточных действий. Это служит мотивом для последующих определений, в которых непринятия усилены до подготовленных непринятий.

Допустим, и допустим, L⁽¹⁾ обозначают одноэлементные множества L вместе с пустым множеством

Определение 5. (Непринятие). Если X является подмножеством L, мы говорим, что P осуществляет непринятие X тогда и только тогда, когда P является стабильным и . Мы утверждаем, что P может осуществить неприятие X тогда и только тогда, когда существует P', такое что и P' осуществляет непринятие X.

Определение 6. (Готовность). Если Y (L⁽¹⁾ , мы утверждаем, что P готов на Y тогда и только тогда, когда P стабилен и ((Y подразумевает Заметим, что любой стабильный процесс тривиально готов на 0.

Определение 7. (Подготовленное неприятие). Если X (L и Y (L⁽¹⁾ , мы говорим, что P может осуществить непринятие X, хотя готов на Y, тогда и только тогда, когда P может осуществить неприятие X из состояния, которое готово на Y, то есть существует P', такой что P' осуществляет непринятие X, и P' готов на Y.

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

Определение 8. (Отношение соответствия). Бинарное отношение R на процессах называется отношением соответствия тогда и только тогда, когда всякий раз, когда P R Q, то сохраняются следующие условия:

C1. Если то существует Q', такое что и P' R Q'

C2. Если P может осуществить непринятие X, в то время как является готовым на Y, то Q может осуществить непринятие X, в то время как готов на Y.

Условие [C2] в определении 8 может показаться неожиданным. Оно дополнительно мотивировано и обсуждено далее, включая раздел 3.3 и раздел 3.4.

Если R ₁ и R ₂ являются бинарными отношениями на процессах, мы определяем их композицию, обозначаемую R ₁oR ₂ через:

R ₁oR ₂={(P,Q)|∃R.(P,R)∈R ₁ ((R,Q)∈R ₂}.

Лемма 1. Допустим, что {R _i}_i∈I является семейством отношений соответствия. Тогда

1. Отношение ∪_i∈I R _i является отношением соответствия.

2. Для любого i,j (I отношение R _ioR _j является отношением соответствия.

3. Отношение тождественности на процессах является отношением соответствия.

Лемма 1.1 показывает, что мы можем определить (в качестве отношения наибольшего соответствия посредством применения объединения всех отношений соответствия на пути, который является стандартным для бисимуляции и симуляции [7] в CCS.

Определение 9. (Соответствие ≤) Отношение наибольшего соответствия указано ссылкой как соответствие и обозначено ≤. Мы записываем P (Q для (P,Q) (≤, и мы говорим, что P соответствует Q.

Условие [С2] определения 8 гарантирует, что, если P (Q, то Q становится в тупик на имени a так же часто, как и P. В определении 8 очень важно, что ограничение готовности наложено только на одно имя за раз посредством того факта, что готовые множества Y являются не более чем одноэлементными множествами (в качестве специального случая выбор Y=0 дает результатом стандартное условие непринятий без ограничения готовности). Это предоставляет возможность спецификации быть более неопределенной в сравнении с ее детализациями, поскольку спецификация может решать ее неопределенность порознь для каждого имени. Например, мы имеем a+b (a#b. Рассмотренный через алфавит имен {a,b} процесс a+b осуществляет непринятие {a,b} и готов и на {a}, и на{b}. Процесс a#b осуществляет непринятие из состояния a, и он осуществляет неприятие из состояния b. Из состояния a он готов на {a}, а из состояния b он готов на {b}. Следовательно, условие [С2] удовлетворено. Читатель может пожелать проверить несколько более интересных примеров:

a|b ((a.b)#(b.a), (a.b)#(b.a) (a|b, a|b (a.b+b.a

где мы записываем P (Q тогда и только тогда, когда P (Q и Q (P. Мы также отмечаем, что ((≤, по правилу [CONG] (дополнительные алгебраические свойства соответствия могут быть найдены в [?]).

Утверждение 1. Отношение соответствия (является рефлексивным и транзитивным.

Последующие теоремы устанавливают наши главные теоретические результаты, преконгруэнтность (операторы CCS являются монотонными в отношении соответствия, теорема 1) и заместимость (спецификации могут быть безопасно замещены на процессы, которые им соответствуют, теорема 2). Полные доказательства даны в [?]. Допустим, что C покрывает CCS-контексты, которые являются выражениями процесса с «пустой вершиной» (записанной []) в них:

C::=[]|(P |[])|([]| P)|(α[]+M)(((a)[])

Мы записываем C[Q], чтобы обозначать выражение процесса, которое возникает при замещении Q на пустую вершину в C.

Теорема 1. (Преконгруэнтность). P (Q подразумевает С[P] ≤С[Q].

Теорема 2. (Заместимость). Пусть P (Q. Тогда беступиковость С[Q] на подразумевает беступиковость С[P] на .

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

3.3. Соответствие и детализация устойчивых отказов

Условие [2] в определении соответствия переделано из теории детализации устойчивых отказов в CSP [5, 12], которая базируется на понятиях трассировок и непринятий. В модели стабильных отказов процесс P представлен множеством его отказов. Отказом P является пара , где - ограниченная трассировка P, и X - множество ошибок, то есть множество событий P могут осуществлять непринятие из стабильного состояния после . Процесс P осуществляет детализацию ошибок процесса Q, если трассировки процесса P содержатся в трассировках Q, и ошибки P содержатся в ошибках Q.

В нашем определении соответствия мы используем непринятия, но используя более строгие подготовленные непринятия в условии [C2]. Это вызвано тем требованием, что соответствие должно быть заместимо касательно беступиковости. В качестве примера рассмотрим два процесса P и Q, определенные как:

P=a.0 и Q=a.0+τ.0

Рассмотренными в качестве процессов на множестве меток , ошибками³ процесса P являются: , а ошибками процесса Q являются . Это следует из того, что P осуществляет детализацию ошибок Q. Однако P является тупиковым на a, но Q не становится тупиковым, поскольку его единственной стабильной производной является 0, который не является тупиковым процессом. Отсюда, даже если P осуществляет детализацию ошибок Q, беступиковость Q не подразумевает беступиковость P. Для сравнения, ограничение готовности в условии [C2] в нашем определении соответствия влечет за собой, что P (Q, поскольку P может выполнять действие a из стабильного состояния (сам P), тогда как Q может выполнять действие a только из нестабильного состояния (сам Q).

Обычная модель трассировки, соответствующая беступиковому соответствию, модифицирует модель стабильных отказов, чтобы использовать подготовленные непринятия в их отказах, так что отказом теперь является пара , где R=(X,Y) является подготовленным непринятием, состоящим из множества непринятий X (L и подготовленного множества X (L⁽¹⁾.

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

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

3.4. Соответствие и отличительный признак непринятия

Наше понятие соответствия имеет сходство с отличительным признаком непринятия, который определен в теории тестирования непринятия [10] Иэйна Филлипса. В отличительном признаке непринятия мы можем понять, что происходит после непринятия (или зависания) посредством обращения к рассмотрению множеств непринятий. Следуя [2], мы можем определить отличительный признак непринятия добавлением правила перехода

в том случае, если P осуществляет непринятие X

для X (L. Для ((p(L)∪L мы записываем , если Мы поднимаемся в направлениях обычным путем. Затем, мы определяем трассировки отказов, f-traces(P)={∈(p(L)∪L)*| }. Отличительный признак непринятия, обозначаемый ≤_(f , определен размещением P ≤_(f Q тогда и только тогда, когда f-traces(P) ( f-traces(Q). Это определение захватывает свойства совместного непринятия и готовности. Например, с мы имеем которое показывает, что a является стабильным состоянием, из которого множество {a} подвергается непринятию, и предложена вниманию метка a. Интересно пронаблюдать, что мы имеем a ≤_(f a+τ.0, поскольку переход не может быть удовлетворен a+τ.0. Действительно, отличительный признак непринятия достаточно строг, чтобы гарантировать заместимость для беступиковости. Однако, он более ограничителен по сравнению с соответствием. Рассмотрим процессы P и Q, определенные как:

P=(a+b.c)#(c+b.a)

Q=(a+b.a)#(c+b.c)

Это может быть проверено из определений (или см. подробности в [?]) того, что P (Q, но P ≤_(f Q. Обоснованием того, что мы имеем P (Q, является то, что Q предоставлена возможность выбирать разные производные в качестве свидетельств условий [Cl] и [C2]. Условие [Cl] засвидетельствовано производной (c+b.c) из Q, а [C2] засвидетельствовано производной (a+b.a) из Q.

4. Применение

На основании теории, представленной в разделе 3, мы реализовали средство проверки соответствия, которое может быть использовано для анализа асинхронных программ, написанных на общеизвестных языках программирования. Такие языки (например, С, Java, C#) имеют некоторые возможности (такие как вызовы процедур, указатели, разделяемая память, исключения и объекты), которые громоздки для непосредственного моделирования в CCS (Calculus of Communicating Systems - исчисление общающихся процессов). Наше средство проверки соответствия считает приемлемым язык ZING, который поддерживает такие возможности непосредственно, без необходимости в трудных для понимания средствах кодирования. Рабочая семантика ZING задана в качестве системы помеченных переходов. Все операторы, кроме операторов send и receive (отправки и приема) смоделированы в качестве переходов, помеченных τ-действиями. Переходы из операторов send и receive помечены соответствующими наименованиями каналов (игнорируя значения данных, которые отправляются и принимаются). Заметим, что определение 8 соответствия не делает ссылку на синтаксис CCS и базируется исключительно на семантике системы помеченных переходов. Таким образом, мы можем определить соответствие между двумя ZING-процессами, используя определение 8 непосредственно.

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

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

Фиг.1. Структура системы регистрации хранения (верхняя часть) и два контракта (нижняя часть)

Структура системы регистрации хранения показана на фиг.1 (верхняя часть). Она содержит в себе пять компонентов служб, Shopping Cart service (служба покупательской корзины), InventoryService (служба инвентаризации), OrderService (служба заявок), PublicInventoryService (служба открытой инвентаризации) и InventoryProcessing (инвентаризационная обработка), и, в дополнение, два процесса интерфейса пользователя. Стрелки от службы A и к службе B имеют место, если A использует (является клиентом) B. Каждая из пяти служб имеет ассоциативно связанный контракт, который является спецификацией открытого видимого поведение службы. На фиг.1 (верхняя часть) каждый контракт поименован по ассоциации со службой, которую он определяет. Два из контрактов показаны на фиг.1 (нижняя часть). Контракт задает обменивающийся данными конечный автомат через набор типов сообщений, безотносительно к полезным данным сообщения (сами типы сообщений объявлены в качестве части спецификации контракта надлежащим образом, но опущены здесь для краткости). Например, контракт Shoppingcart (корзина для покупок) указывает, что служба будет повторно вводить сообщения типа AddItem (добавить изделие) or RemoveItem (удалить изделие) до тех пор, пока любое из сообщения Checkout (проверка) или сообщения Cancel (отменить) не принято (мы используем условный знак T? для входных и T! для выходных, где T - тип сообщения). Событие Timeout (таймаут), использованное в контракте InventoryReservation (резервирование товара), является специальным событием. Таймауты могут быть приписаны к конструкциям ввода в языке реализации.

Объявление контракта создает новое наименование типа, идентичное наименованию контракта. Код реализации для службы размещен в объявлении службы (более вероятно, в объявлении класса), которое устанавливает контракт, предполагается его реализовать как в Service ShoppingCartService Implements ShoppingCart{code}

Переменные, удерживающие объекты, которые представляют присоединения к другим службам, типизированы контрактами, описывающими такие службы. Например, последующий оператор в реализации ShoppingCartService создает соединение с InventoryService и продолжается c cont:

InventoryReservation inv=new InventoryService(); cont

Полагаясь на типы контракта, возможно автоматически преобразовать реализацию службы в ZING-модель, которая замещает контракты службами, которые использованы. Поступая так, мы полагаемся на теорему 2. Например, создание соединения, изложенное выше, преобразовывается в ZING-оператор inv=new cInventoryReservation, где cInventoryReservation является ZING-классом, который компилирован из контракта InventoryReservation. В качестве стороннего эффекта для вызова конструктора для этого класса порождается параллельный процесс, который ведет себя так, как задано в контракте. Это соответствует CCS-процессу:

(νinv)(cInventoryReservation(inv) )

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

Анализ соответствия системы учета хранения был сделан посредством компиляции каждой реализации службы и ее ассоциативно связанных контрактов в ZING, имеющей результатом два ZING-процесса, которые затем были сопоставлены, используя наше средство проверки соответствия. Проверка соответствия была сделана композиционно посредством проверки одной реализации службы за раз в отношении спецификации ее контракта, замещая контракты, чтобы представить службы, которые использованы. Весь процесс полностью автоматический. Наш анализ соответствия обнаруживал некоторое количество ошибок, включая зависание, которые кратко описаны ниже. В перечне, приведенном ниже, мы показали, какой контракт был проверен, и какое условие ([C1] или [C2]) определения 8 было нарушено; мы также показали провал теста на тупиковость, упомянутый выше. Мы подчеркиваем, что эти ошибки не были найдены до того, как мы проверяли код. (Код не был протестирован целиком. Заметим, однако, что некоторые из ошибок типично не могут быть найдены при тестировании).

(1) InventoryReservation. Отсутствующая спецификация таймаута ([C2]). Контракту недостает задавать, что служба должна отрабатывать таймаут в ее событийном цикле. Это имело результатом отказ подготовленного непринятия, идентифицированный средством проверки соответствия, поскольку служба может отвергать все запросы после того как таймаут истечет. Контракт был исправлен добавлением блока Timeout. Событие таймаута моделируется в качестве внутреннего (τ) действия, и когда присоединено ко входу α, оно представлено на ZING как α+τ.0 (полагая здесь, что ничего не происходит после таймаута).

(2) InventoryReservation. Не задан повторный ввод ([C1]). После исправления предшествующей ошибки средство проверки соответствия сообщало об отказе симуляции. Проблема была в том, что контракт указывал, что служба забирает сообщение CommitReservation только однажды, завершая событийный цикл службы. Однако, реализация службы не завершала ее рабочий цикл по приему CommitReservation, как должна была, и реализация была исправлена.

(3) ShoppingCart. Тупиковость. Фиг.1 показывает контракт ShoppingCart и исправленный InventoryReservation. Реализация использует службу InventoryService и Ordering. Проверка соответствия находит, что реализация службы становится в тупик с контрактом InventoryReservation в ситуации, когда служба принимает сообщение Checkout, затем продолжает отправлять сообщение CommitReservation службе InventoryService и затем ожидает приема Acknowledgement. Этот прием зависает, если InventoryService отработало таймаут. В другой ситуации таймаут служит причиной тупиковости из-за остаточных сообщений, отправляемых из ShoppingCartService. Реализация была исправлена.

(4) Inventory. Вход не реализован в службе([C2]). Вход, указанный в контракте Inventory, но не реализованный, имел результатом отказ неприятия. Реализация была исправлена.

(5) InventoryChangeNotification. Входы не доступны после приема конкретного сообщения ([C2]). В одном конкретном состоянии по приему сообщения Done в его событийном цикле службы служба PublicInventoryService будет выходить из ее событийного цикла, не завершая обмен данными с системой открытой подписки в службе InventoryProcessing, несмотря на то, что контракт не отражает эту возможность. Сообщения для такой системы, следовательно, могли быть потеряны, и реализация была исправлена.

4. Вывод

Мы представили новое отношение детализации для CCS, которое пригодно для композиционной проверки беступиковости обменивающихся данными процессов. Соответствие имеет преимущество в том, что является непосредственно применимым к системе помеченных переходов, в которой могут наблюдаться явные действия и стабильность. Тупиковость является более избирательной, чем взаимоблокировка в CSP, из-за того, что учитывает зависшие сообщения, что является полезным для проверки асинхронных процессов. Мы доказывали, что соответствие является преконгруэнтностью на CCS процессах, удовлетворяющей заместимости, и мы отделили его от имеющих отношение отличительных признаков процесса. Мы создали средство проверки соответствия для ZING наглядного языка моделирования и применили его к распределенной системе.

Литература

1. Р.Алюр, Т.А.Хензингер, О.Купферман и М.Й.Варди. Альтернативные отношения детализации. CONCUR 98: Теория совместного выполнения.

2. Е.Бринксма, Л.Хиринк, Дж.Тритманс. События при тестировании систем переходов. Тестирование обменивающихся данными систем, IFIP TC6 10-ый международный семинар по тестированию обменивающихся данными систем.

3. К.Д.Брукс, К.А.Р.Хоар и А.В.Раску. Теория обменивающихся данными последовательных процессов.

4. Л.Деалфано и Т.А.Хензингер. Теории взаимодействия для компонент-ориентированной разработки.

5. К.А.Р.Хоар. Обменивающиеся данными последовательные процессы.

6. К.Г.Ларсен и А.Скоу. Двоичная имитация посредством вероятностного моделирования. ACM-принципы языков программирования

7. Р.Милнер. Обмен данными и совместное исполнение.

8. Р.Милнер. Обмен данными и мобильные системы: π-исчисление

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

10. И.Филипс. Тестирование отказов.

11. С.К.Раджамани и Дж. Рехоф. Проверка соответствия для моделей передающего асинхронные сообщения программного обеспечения.

12. А.В.Раску. Теория и практика совместного исполнения.

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

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

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

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

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

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

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

7. Система по п.6, в которой компонент расширения контракта расширяет компонент контракта для добавления по меньшей мере одного дополнительного состояния к компоненту контракта.

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

9. Машиночитаемый носитель, содержащий сохраненные на нем машиночитаемые команды для реализации системы по п.1.

10. Компьютер, содержащий процессор для применения системы по п.1.

11. Веб-ориентированная среда, выполненная с возможностью применения системы по п.1.

12. Машиночитаемый носитель, содержащий сохраненные на нем компоненты по п.1.

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

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

15. Способ по п.14, в котором действие по объявлению контракта дополнительно содержит задание шаблона для исполнения по меньшей мере одного компонента сообщения.

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

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

18. Способ по п.14, в котором действие по объявлению контракта дополнительно содержит идентификацию компонента расширения контракта, который расширяет существующий контракт.

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

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

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

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

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

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

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

26. Способ по п.25, дополнительно содержащий сообщение регламента алгоритму рабочего цикла.

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

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

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