Реализация совместно исполняющихся программ на объектно-ориентированных языках

Реализация совместно исполняющихся программ на объектно-ориентированных языках

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

Объектно-ориентированные (ОО) оболочки, например, сред торговых марок 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 может принимать сообщение через конкретный соединитель, блокируясь до тех пор, пока сообщение не прибудет. Отсутствующее выражение соединителя подразумевает, что сообщение будет принято через первичный соединитель и разрешено только