ПЛАТФОРМА СОСТАВНЫХ ПРИЛОЖЕНИЙ НА БАЗЕ МОДЕЛИ Российский патент 2013 года по МПК G06F17/00 

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

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

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

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

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

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

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

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

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

Фиг.1 иллюстрирует примерное высокоуровневое представление архитектуры или платформы в соответствии с одним или несколькими вариантами осуществления.

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

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

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

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

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

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

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

Фиг.9 иллюстрирует примерное окружение служб процессов в соответствии с одним или несколькими вариантами осуществления.

Фиг.10 иллюстрирует примерное окружение служб каталогов в соответствии с одним или несколькими вариантами осуществления.

Фиг.11 иллюстрирует примерное окружение служб доступа в соответствии с одним или несколькими вариантами осуществления.

Фиг.12 иллюстрирует примерное окружение служб интеграции в соответствии с одним или несколькими вариантами осуществления.

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

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

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

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

Фиг.17 иллюстрирует примерную систему, которая может использоваться для реализации одного или нескольких вариантов осуществления.

Подробное описание

Общее представление

Как отмечалось выше, приложения, которые создаются путем объединения нескольких модулей, называются "составными приложениями". Разные части составного приложения (например, клиентская часть, часть бизнес-процессов, часть хранилища данных и т.п.) могут работать в совершенно разных окружениях (например, ASP.NET, BizTalk, SQL Server), что значительно увеличивает трудность работы с приложением в целом. К тому же разные моменты в жизненном цикле составного приложения часто плохо автоматизированы, если это вообще имеет место. На сегодняшний день инфраструктура составных приложений накладывает свои требования, например, не так уж необычно для продвинутых авторов составных приложений сообщить, что они тратят более 90% ресурсов на написание инфраструктурного кода. Поскольку распределенная обработка и пропускная способность становятся все более повсеместными, бизнес и другие сталкиваются с заманчивым разрывом между тем, что они задумывают и тем, что они могут позволить себе создавать, развертывать и управлять.

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

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

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

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

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

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

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

Составные приложения

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

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

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

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

Примерная архитектура или платформа

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

Фиг.1 иллюстрирует примерное высокоуровневое представление архитектуры или платформы в соответствии с одним или несколькими вариантами осуществления, в целом по ссылке 100. Архитектура 100 в этом примере включает в себя пять логических компонентов - компонент 102 связующих служб, компонент 104 служб процессов, компонент 106 служб идентификации, компонент 108 служб обеспечения жизненного цикла и компонент 110 инструментария. Эти отдельные компоненты архитектуры имеют собственные подкомпоненты, каждый из которых описывается в соответствующем подразделе ниже.

Вкратце, компонент 102 связующих служб в этом примере включает в себя компонент 112 сервисной шины, компонент 114 служб обработки транзакций и компонент 116 служб сообщений. Компонент 104 служб процессов включает в себя компонент 118 технологических процессов/правил. Компонент 106 служб идентификации включает в себя компонент 120 служб каталогов и компонент 122 служб доступа. Компонент 108 служб обеспечения жизненного цикла включает в себя компонент 124 репозитория, компонент 126 интеграции, исполнительный компонент 128 и аналитический компонент 130. Компонент 110 инструментария включает в себя компонент 132 на базе кода (например, Visual Studio), инструмент 134 на базе модели (например, Quadrant) и инструмент 136 управления предприятием (например, компонент System Center).

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

Компонент связующих служб

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

Компонент сервисной шины

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

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

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

На практике приложения используют сервисную шину, чтобы обмениваться информацией со службами или другими приложениями. Относительно служб и приложений рассмотрим следующую аналогию. Службы являются компонентами составных приложений точно так же, как объекты являются компонентами локальных приложений. Когда кто-то пишет объектно-ориентированное приложение, все приложение является объектом, и тогда некто пишет этот объект в понятиях других объектов. Точно так, когда кто-то пишет сервисноориентированное приложение, приложение могло бы быть службой, и тогда некто мог бы писать эти службы в понятиях других служб. В конечном счете службы имеют локальную реализацию, и они пишутся с помощью объектов. Перед взаимодействием с другим приложением или службой в некоторых вариантах осуществления приложение может искать и находить конкретную сущность, с которой нужна связь. С этой целью сервисная шина предоставляет компоненты поиска и обнаружения, которые дают возможность обнаружения приложений или служб (посредством, например, сетевого адреса), с которыми приложение желает обмениваться информацией. В качестве альтернативы или дополнительно может моделироваться шаблон связи, и сущность, с которой нужна связь, может идентифицироваться в конкретной модели. К тому же сервисная шина включает в себя функциональные возможности синхронизации, которые действуют для обеспечения того, что синхронизируются данные между сущностями, которые взаимодействуют по сервисной шине. То есть сервисная шина в некоторых вариантах осуществления может предоставлять шаблон связи на основе сообщений и шаблон связи на основе данных. Шаблон связи на основе сообщений мог бы устанавливать, например, что A отправляет сообщения B, или A многоадресно рассылает сообщения B1, B2, B3, B4 и так далее. Шаблон связи на основе данных, с другой стороны, может установить, что если A изменяет данные, то инициируются все участники, заинтересованные в изменениях в тех данных. Затем любой заинтересованный участник может считать или изменить данные в любое время. Протоколы, используемые для передачи этой информации или данных, являются конфигурируемыми и расширяемыми.

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

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

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

В качестве лишь одного примера сервисной шины в соответствии с одним или несколькими вариантами осуществления рассмотрим фиг.2. Там показан примерный компонент сервисной шины, в целом по ссылке 200. В этом примере компонент 200 сервисной шины включает в себя уровень 202 кодеров, уровень 204 каналов и различные другие компоненты верхнего уровня, которые обеспечивают функциональные возможности, описанные выше и ниже. В частности, в этом примере компонент 200 сервисной шины включает в себя компонент 206 обнаружения, компонент 208 федеративных пространств имен, компонент 210 федеративной идентификации и компонент 212 ретрансляции. Когда компонент ретрансляции встраивается в сервисную шину, тогда участникам сервисной шины можно обмениваться информацией между конечными точками, которые разделены межсетевыми экранами или иным образом являются взаимно неадресуемыми. Функциональные возможности ретрансляции могут быть реализованы с использованием сочетания расширенных сетевых свойств и посредников, видимых обеим конечным точкам, чтобы достичь этой цели, что будет понятно специалисту.

В этом примере уровни 202, 204 кодеров и каналов обеспечивают функциональные возможности, которые разрешают прямую связь. При этом условии уровень 202 кодеров поддерживает некоторое количество разных стандартов кодирования, например, SOAP, XBIN, POX/RSS и т.п., а также наборов символов (кодировок). Уровень 204 каналов содержит разные компоненты, которые облегчают прямую связь. В качестве примера, а не ограничения, эти компоненты включают в себя компоненты прослушивателя, транспортные компоненты, компоненты адаптера и компоненты свойств.

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

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

Компоненты адаптера могут выглядеть как транспортные компоненты для их пользователей. Компоненты адаптера заключают в оболочку источники или приемники сообщений и делают их выглядящими как транспортные компоненты. По меньшей мере в некоторых вариантах осуществления могут быть разные типы компонентов адаптера. Например, компоненты адаптера для отрасли производства (LOB) охватывают отраслевые системы, такие как SAP или Peoplesoft. Компоненты адаптера обмен сообщениями охватывают инфраструктуру или посредников обмена сообщениями типа DCOM, MSMQ, MQ или TibCo.

Компоненты свойств являются компонентами, которые реализуют свойства в конечной точке, которые не являются кодерами или транспортами. Они включают в себя компоненты протоколов типа WS-Security или WS-RM, компоненты преобразования и фильтрации, типа встречающихся в конвейерах BizTalk, и компоненты протокольного переноса.

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

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

В дополнение к обработке сообщений и работе в качестве низкоуровневой двухточечной транспортной службы компонент 200 сервисной шины также включает в себя высокоуровневые компоненты, например проиллюстрированный компонент 206 обнаружения, компонент 208 федеративных пространств имен, компонент 210 федеративной идентификации и компонент 212 ретрансляции.

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

Это может быть реализовано с помощью инфраструктуры обмена сообщениями в случаях с адаптерами, которые охватывают инфраструктуру, у которой есть собственные присвоенные имена. Это также может быть реализовано с помощью сервера обнаружения в случаях, где служба, использующая легкий транспорт (HTTP), желает зарегистрировать имена в сервисной шине. Фиг.3 в целом по ссылке 300 иллюстрирует окружение, в котором компонент федеративных пространств имен может работать в соответствии с одним или несколькими вариантами осуществления. Здесь компонент федеративных пространств имен включает в себя два уровня - уровень 302 сближения и уровень 304 пространств имен. Эти уровни показаны логически помещенными между уровнем 306 каналов (который соответствует уровню 204 каналов в шине сообщений из фиг.2 и который используется для прямой связи) и некоторым количеством свойств, которые могут быть созданы поверх уровня 304 пространств имен. Эти дополнительные свойства логически изображаются по ссылке 308 и включают в себя, в качестве примера, а не ограничения, службы обнаружения, службы уведомления, службы каталогов и службы сервера сообщений. Все эти службы могут использовать уровень 304 пространств имен, чтобы по существу "подключиться" к платформе и использовать функциональные возможности пространства имен для предоставления богатого набора функциональных возможностей.

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

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

Дополнительные свойства, в целом показанные по ссылке 308, являются либо применениями этой инфраструктуры, либо службами, которые создаются поверх них. Например, "Обнаружение" иногда может относиться к возможности изучать имена поверх адресного пространства, чтобы найти имена, ассоциированные с некоторыми видами метаданных. "Обнаружение" также может относиться к службе поверх этой инфраструктуры, которая отслеживает ассоциации метаданных/адресов и предлагает эту информацию по стандартным протоколам обнаружения, например UDDI, WS-Discovery и т.п. "Уведомление" относится к возможности регистрировать службу по именам, на которые отправляются уведомления. "Каталог" относится к приложению, которое предоставляет услуги управления набором репозиториев (например, контроль доступа, контроль репликации и т.п.). "Сервер сообщений" относится к службам, которые существуют в/на компоненте, который обеспечивает надежность и/или устойчивость пользователям компонента.

В одном или нескольких вариантах осуществления компонент 210 федеративной идентификации (фиг.2) предоставляет архитектуру и парадигму безопасности для платформы. В качестве одного примера архитектуры безопасности рассмотрим фиг.4. Там примерная архитектура или система безопасности показана в целом по ссылке 400. Здесь система 400 включает в себя один или несколько компонентов 402 технологической службы сервера, которые управляют маркерами, диспетчер 404 политик, система 406 CardSpace, агент 408 CardSpace, диспетчеры 410, 418 маркеров безопасности, клиент 412, служба 414 и диспетчер 416 авторизации служб.

В работе и в соответствии с одним или несколькими вариантами осуществления архитектура 400 безопасности работает следующим образом. В стеке сообщений, когда клиент 412 хочет использовать службу 414, клиент 412 делает это путем использования утверждения, например ключа. Утверждение может рассматриваться на элементарном уровне в качестве данных, которые составляют утверждение некоторого факта. Целостность и секретность утверждений защищается посредством методик безопасности. Соответственно в этом примере клиент 412 взаимодействует с диспетчером 410 маркеров безопасности, чтобы установить, существует ли утверждение или ключ, ассоциированный со службой 414, который он может использовать для использования службы 414. Политика, ассоциированная со службой 414, идентифицирует утверждения, которые необходимы для доступа к службе 414, либо могут использоваться протоколы безопасности для запроса у службы 414, что нужны утверждения. Клиент 412 передает утверждения, которые у него есть, и информацию об утверждениях, которые ему нужны, диспетчеру 410 маркеров безопасности. Диспетчер маркеров безопасности обращается к различным хранилищам политик утверждений (например, системе 406 CardSpace и/или диспетчеру 404 политик), чтобы установить, какие утверждения он может предоставить клиенту 412 для использования в обмене информацией. В этот момент клиент 412 взаимодействует со службой 414, которая принимает утверждения, предоставленные клиентом 412. Служба 414 подвергается аналогичному процессу утверждений-разрешения с помощью диспетчера 416 авторизации служб. Вновь набор утверждений, предоставленный клиентом 412, может дополняться на серверной стороне утверждениями, ассоциированными с утверждениями клиента в хранилище политик сервера. В конечном счете этот процесс завершается, и вычисляется итоговый набор утверждений клиента. Если набор утверждений включает в себя утверждение, необходимое для взаимодействия со службой 414, то предоставляется доступ.

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

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

Компонент служб обработки транзакций

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

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

В частности, модель программирования может включать в себя как управляемый код 508, так и машинный код 510. Стек 504 транзакций может включать в себя API 512 транзакций систем, координатор 514 распределенных транзакций (DTC) и компонент 516 KTMRM, который взаимодействует с компонентом 518 KTM режима ядра, как показано. Ресурс 506 может включать в себя некоторое количество разных типов ресурсов, например ресурсы 520 баз данных, ресурсы 522 MDAC, локальные и удаленные координаторы 524 распределенных транзакций, ресурсы 526 HIS, взаимодействие 528 с TM/RM, удаленные ТМ 530, TxF 532 и TxR 534.

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

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

В проиллюстрированном варианте осуществления показаны пять разных примеров шаблонов взаимодействие с различными диспетчерами или координаторами транзакций. В этом примере KTM 518 является диспетчером транзакций для кода ядра и используется в основном по отношению к файлам и реестру. KTM 518 может согласовываться с DTC 514 и через DTC 514 с другими удаленными диспетчерами транзакций (то есть с локальными и удаленными DTC 524, HIS 526, взаимодействием 528 с TM/RM и удаленными ТМ 530). KTM 518 может разрешить изменения в файлах и настройках реестра. Проиллюстрированный пример показывает как механизм, используемый для взаимодействия с другими координаторами транзакций (то есть Ole TX, LU6.2 и т.д.), так и тип координатора транзакций, с которым происходит взаимодействие. Координаторы транзакций используют разновидность стратегии "главный-подчиненный", причем создатель является главным, а другие координаторы являются подчиненными.

База 520 данных и MDAC 522 являются примерами ресурсов, чьи изменения состояния координируются посредством DTC 514. Другие удаленные координаторы транзакций имеют дело с другими диспетчерами ресурсов. Когда диспетчеров ресурсов просят изменить состояние "в" транзакции, они должны убедиться, что они представляют вид этого состояния, как если бы изменение выполнялось для каждого, кто сопровождает эту же транзакцию. Более того, они блокируют доступ к состоянию любым другим сущностям. С помощью выполнения этого и затем завершения изменения в состоянии поддерживаются хорошие условия состояний.

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

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

Компонент служб сообщений

В одном или нескольких вариантах осуществления компонент 116 служб сообщений (фиг.1) предоставляет высокоуровневую услугу посреднического обмена сообщениями, например устойчивость и постоянные запросы. Компонент служб сообщений может быть реализован в качестве размещенной службы, которая может работать в автономном режиме, в "кластеризованном" режиме, где несколько служб взаимодействуют напрямую, или в "распределенном" режиме, где службы могут работать на клиентах, на серверах предприятия и/или на серверах, размещенных в сети, такой как Интернет. В одном или нескольких вариантах осуществления компонент служб сообщений реализует общие шаблоны обмена сообщениями, например организация очереди и публикация/подписка (также называется "pub/sub"), и более ценные свойства типа маршрутизации на основе содержимого и соотнесения событий. В проиллюстрированном и описанном варианте осуществления к службам сообщений обращаются через канальную абстракцию шины сообщений (описанную выше), которая обеспечивает как стандартный API, так и гибкость в той мере, как и протоколы, и затрагивается интеграция. В нижеследующем обсуждении примерный узел сообщений сначала описывается применительно к фиг.6. Исходя из этого предоставляется пример того, как узлы сообщений могут соединяться вместе, чтобы проиллюстрировать гибкость и сильную взаимосвязанность, которую обеспечивает описанная архитектура.

В качестве лишь одного примера архитектуры, которая может использоваться для реализации функциональных возможностей, описанных немного выше, рассмотрим фиг.6. Там система 600 включает в себя так называемый отдельный узел 602 сообщений. Узел 602 сообщений в этом примере включает в себя некоторое количество компонентов или составляющих частей. В частности, первый уровень узла включает в себя компонент 604 управления подпиской, компонент 606 сбора и компонент 608 доставки, каждый из которых предоставляет гибкий набор интерфейсов прикладных программ (API), чтобы реализовать свои функциональные возможности. Этот уровень в основном имеет дело с обработкой сообщений, входящих и выходящих из узла.

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

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

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

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

В одном или нескольких вариантах осуществления третий уровень включает в себя модуль 614 маршрутизации на основе содержимого, который может реализовывать маршрутизацию на основе содержимого. Маршрутизация на основе содержимого имеет отношение к понятию отправки содержимого другим узлам на основе конкретного содержимого, что будет понятно специалисту. Это может позволить упрощенную обработку для крупных распределенных систем массового обслуживания на узле. Например, если сообщение отправляется в систему pub/sub и сообщение имеет отношение к погоде в штате Нью-Йорк, то маловероятно, что кто-то в Калифорнии проявляет интерес к этому сообщению. Поэтому маршрутизация на основе содержимого могла бы тогда отправить сообщение вычислительным устройствам только в штате Нью-Йорк.

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

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

Описав понятие узла обмена сообщениями, рассмотрим теперь различные пути, которыми узлы обмена сообщениями могут быть соединены вместе, применительно к фиг.7. Там окружение 700 связи показано в целом по ссылке 700. Окружение 700 включает в себя некоторое количество разных принципов связности в соответствии с одним или несколькими вариантами осуществления. Здесь имеется некоторое количество хостов - хосты 1-8, часть которых работает как узлы 602 службы сообщений (фиг.6).

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

Хосты 2 и 3 иллюстрируют, что два узла могут быть связаны напрямую, используя компонент 612 передачи (фиг.6). Соответственно, сообщение, которое могло бы быть захвачено на хосте 2, может быть введено в систему. Если сообщение соответствует подписке на хосте 3, то сообщение может быть просто отправлено хосту 3.

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

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

Хосты 5, 7 и 8 иллюстрируют другие сценарии. Например, хост 5 иллюстрирует то, как проприетарные протоколы могут использоваться для обмена информацией с другими pub/sub-системам - здесь BizTalk Server. Хост 7 иллюстрирует, как другие обеспечивающие взаимодействие протоколы, например протоколы взаимодействия WS-*, могут использоваться для обмена информацией между узлом службы сообщений и некоторой другой сторонней службой очередей, которая также оказывается понимающей обеспечивающий взаимодействие протокол, и эта служба может затем доставить сообщения их приложению в любом виде, который им нравится.

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

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

Компонент служб процессов

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

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

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

Составные части компонента сервера процессов включают в себя, в качестве примера, а не ограничения, службу 810 активации, компонент 812 соотнесения экземпляра/сеанса, среду выполнения, которая включает в себя компонент 814 общеязыковой среды выполнения, обработчик 816 правил (который выполняет действия, зависящие от изменений состояния), обработчик 818 технологических процессов (который допускает описание либо одиночных действий, либо графов действий, который будут запускаться обработчиком правил) и библиотеки 820 действий (которые формируют предопределенные или предварительно сконфигурированные действия). Сервер процессов также включает в себя программы 822 на предметно-ориентированном языке.

В работе в этом примере все сообщения, которые поступают для запуска работы на компоненте сервера процессов, поступают из сообщения или от сервисной шины 804. Компонент 812 соотнесения экземпляра/сеанса изучает входящие сообщения и решает, могут ли они быть направлены существующему экземпляру среды выполнения и прикладного модуля пользователя. Эти экземпляры могли бы находиться в памяти, или они могли бы быть на диске. Служба 810 активация также создает новые экземпляры среды выполнения и пользовательской программы по требованию входящего потока сообщений (то есть создается новый экземпляр, если существующий экземпляр уже не является подходящим). У сервера процессов есть среда выполнения, подходящая для декларативных программ (технологического процесса, правил), управляемых императивных программ (С#, VB.NET) и неуправляемых императивных программ (С++, С). Более того, у сервера процессов есть реальные программы (которые могут быть или не быть DSL).

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

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

Процессы могут создаваться с использованием обширного набора ресурсов. В частности, процессы могут создаваться с использованием компонента 814 общеязыковой среды выполнения (CLR). Обработчик 816 правил предоставляет платформу технологических процессов и может быть расширен для запуска процессов с использованием одних лишь правил. Таким образом, программы могут создаваться с использованием одних лишь правил. Обработчик 818 технологических процессов может создаваться поверх правил, и поверх этого могут создаваться библиотеки, достаточные для разрешения разработчикам писать программы без написания какого-либо кода, по меньшей мере в некоторых случаях предоставляя, таким образом, программу, содержащую объединенные в пакет компоненты и модели. Программа является исполняемой моделью. Модель может изображаться графически, на текстовом языке или в репозитории. В проиллюстрированном и описанном варианте осуществления CLR является общеязыковой средой выполнения, которая составляет ядро.NET. CLR является виртуальной машиной и средой выполнения, которые вместе могут выполнять логические коды операций, в которые компилируется код на C# и VB.NET. Правила являются парами условие/действие. Условия соединяются с данными, которые иногда могут быть неизменными данными, а иногда могут быть данными, которые представляются правилам. Действия срабатывают, когда правило соответствует данным.

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

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

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

Там примерная среда показана в целом по ссылке 900. В работе сообщения выходят из сервисной шины через так называемые порты 902, ассоциированные с маршрутизатором 904. Таким образом, сообщения идут через порт в маршрутизатор. Порты являются конечными точками, ассоциированными с сервисной шиной, и соответствуют стекам каналов, описанным на фиг.2. Маршрутизатор в этом варианте осуществления обладает функцией в распределенной среде, которая аналогична диспетчеру экземпляров на фиг.8. Маршрутизатор вычисляет, находится ли экземпляр уже в одном из серверов процессов или является ли он новым экземпляром. Если сообщение предназначено для существующего экземпляра, то маршрутизатор отправляет сообщение серверу процессов, который хранит экземпляр. Если сообщение предназначено для нового экземпляра (или для экземпляра, не закрепленного в настоящее время за конкретным сервером процессов), то маршрутизатор выбирает сервер процессов и затем перенаправляет сообщение. Часть с экземпляром у сервера процессов сопоставляется с маршрутизатором.

По меньшей мере в некоторых вариантах осуществления протоколы могут использоваться для ассоциации сообщений с экземплярами длительных процессов. В проиллюстрированном и описанном варианте осуществления имеется пара способов, как это может работать. Например, сообщение могло бы содержать заголовки для конкретного протокола создания экземпляров. Это упрощает работу с логикой экземпляра-расположения. Если, с другой стороны, сообщение не содержит заголовки протокола создания экземпляров, то функция сопоставления создает информацию, которая была бы в протоколе на основе информации в сообщении, которое однозначно идентифицирует экземпляр (например, заказ на приобретение для экземпляра). Это может выполняться путем использования базы 906 данных идентифицирующих свойств. Свойства могут определять то, как сообщение должно быть сопоставлено с экземпляром через преобразование в порте. Продолжая, сообщения поступают в порт и затем отправляются маршрутизатору 904. Маршрутизатор выясняет, какие серверы процессов работают, посредством базы 908 данных серверов процессов. В этом примере это выполняется с использованием таблицы, которая отслеживает работающие серверы процессов. База данных или хранилище 910 сопоставления экземпляров отслеживает экземпляры, которые ассоциируются с одним из серверов процессов. Маршрутизатор выясняет, к какому серверу процессов нужно направить сообщение. Это выполняется посредством хранилища 910 сопоставления экземпляров, которое хранит сопоставление экземпляров процессов с серверами процессов. Маршрутизатор может затем направить сообщение надлежащему серверу процессов, который, в свою очередь, может направить сообщение надлежащему экземпляру. Для существующего экземпляра маршрутизатор 904 выясняет, где работает экземпляр, чтобы он мог отправить сообщение правильному серверу 912, 914 и 916 процессов. Если экземпляр является новым или если экземпляр в настоящее время не сопоставлен с сервером процессов, то маршрутизатор 904 выбирает сервер процессов из числа работающих серверов процессов. Иначе или дополнительно могла бы произойти ситуация, что прошел длительный период времени (например, 3 недели), с тех пор как поступило сообщение для конкретного экземпляра. В этом случае конкретный экземпляр может быть помещен обратно в хранилище 918 состояний экземпляров. В таком случае извлекается состояние экземпляра и вносится в память подходящего сервера процессов.

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

Компонент служб идентификации

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

В качестве лишь одного примера компонента служб каталогов рассмотрим фиг.10, которая иллюстрирует примерную систему в целом по ссылке 1000. В этом примере компонент служб каталогов включает в себя то, что может рассматриваться как уровень 1002 доступа и стек 1004 каталогов. Уровень 1002 доступа включает в себя один или несколько компонентов, посредством которых может быть показан стек каталогов. В проиллюстрированном и описанном варианте осуществления эти компоненты включают в себя компонент 1006 API, компонент 1008 API обмена сообщениями (MAPI), компонент 1010 KDC и/или компонент 1012 сервисной шины.

Компонент 1006 API может рассматриваться как традиционный API или стандартный API, который при желании может использоваться для доступа к стеку каталогов. Здесь API в компоненте API более определенно связаны с данными, которые доступны в стеке каталогов.

Компонент 1008 MAPI относится к интерфейсам программирования, которые используются подсистемами MAPI, авторами клиентских приложений и авторами поставщиков услуг. Основной интерфейс программирования является объектным интерфейсом, известным как интерфейс программирования MAPI. На основе модели компонентных объектов OLE интерфейс программирования MAPI используется подсистемой MAPI и клиентскими приложениями и поставщиками услуг на основе обмена сообщениями, написанными на C или C++, что будет понятно специалисту.

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

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

В проиллюстрированном и описанном варианте осуществления стек 1004 каталогов содержит компоненты, включающий агент 1014 службы каталогов, который включает в себя компонент 1016 репликации, компонент 1018 доступа к данным и основной модуль 1020 безопасности. Дополнительно стек каталогов также включает в себя репозиторий 1022 и хранилище 1024. В этом примере репозиторий является сущностью, которая хранит данные в виде, который может использоваться платформой, описанной в этом документе. Поэтому он может рассматриваться как служащий в качестве хранилища для данных в "новом формате". Аналогичным образом хранилище 1024 служит в качестве хранилища для того, что может считаться существующими данными или данными в прежнем формате. В этом конкретном примере основной модуль 1020 безопасности обеспечивает уровень безопасности для хранилища 1024, чтобы оно представлялось правильно для компонента 1018 доступа к данным.

Агент 1014 службы каталогов может рассматриваться как общий уровень, который все разные API доступа используют для взаимодействия с системой баз данных. Этот программный уровень понимает расположение других хранилищ данных в системе. По существу, он использует эти сведения для доступа к данным (например, в случае, где API пытаются получить некоторую информацию, которая не доступна в локальных хранилищах), и он также использует эти сведения для репликации (например, помещение данных в стратегические положения повсюду в сети, чтобы к ним можно было обращаться эффективно оттуда, где они нужны). Этот механизм распределенного доступа имеет место между различными агентами службы каталогов (например, сущность "другой DSA" на фигуре). Поскольку эта информация оказывается доступной на этом уровне, информация домена также предоставляется системе DNS от агента службы каталогов, чтобы отслеживать имена компьютеров, IP-адреса и подсети и т.п.

В этом примере компонент 1018 доступа к данным используется для разрешения не только компоненту 1006 API (то есть традиционному API) обращаться к данным, которые он исходно не планировал для доступа, но также для разрешения компоненту 1012 сервисной шины обращаться к существующим данным.

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

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

В качестве примерной архитектуры службы доступа рассмотрим фиг.11, которая иллюстрирует систему в целом по ссылке 1100. Здесь система 1100 включает в себя репозиторий 1102, сервисную шину 1104 и технологическую службу 1106 сервера, логически помещенные между репозиторием и сервисной шиной. Здесь служба 1106 включает в себя компонент 1108 политик доступа и сервер 1110 процессов. Сервер 1110 процессов включает в себя компонент 1112 технологических процессов и компонент 1114 правил. Здесь компонент 1108 политик доступа содержит соответствующие политики для доступа к ресурсам. Компонент 1112 технологических процессов и компонент 1114 правил задают или иным образом описывают отношения доступа. Эти компоненты работают на сервере, чтобы реализовать технологическую службу сервера, которая предоставляет доступ к ресурсам. В частности, в одном или нескольких вариантах осуществления служба доступа, которая реализована архитектурой службы доступа, содержит сервер процессов, выполняющий специальную программу с подходящими интерфейсами, чтобы встроиться в архитектуру из фиг.4.

Компонент служб обеспечения жизненного цикла

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

Рассмотрим сначала компонент интеграции применительно к фиг.12. Там система 1200 включает в себя компонент интеграции в виде сервера 1202 интеграции, логически помещенного между репозиторием 1204, компонент 1206 метабазы и множество источников 1208 данных. Одной из областей деятельности компонента интеграции является способность выверять данные, которые могут постоянно находиться в разных хранилищах на предприятии. Для выполнения этого и как описано ниже, компонент интеграции способен "подключиться" ко всем разным хранилищам данных, которые могли бы использоваться на предприятии. К тому же особые типы декларативных программ, работающих в компоненте интеграции, предназначены для реализации политик, используемых предприятием для рассмотрения возможных конфликтов. К тому же другой из областей деятельности компонента интеграции является создание унифицированного или единого представления для приложения на данные, которые постоянно находятся в разных местах, например разных базах данных, разных приложениях LOB и т.п. Таким образом, в этой попытке приложение определяет и устанавливает рабочее представление данных, распознает сопоставление между представлением приложения и подлежащими хранилищами данных и затем устанавливает политики для выверки изменений в хранилищах данных с изменениями в представлении приложения. Эти политики обычно находятся в логике приложения.

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

В этом примере сервер 1202 интеграции включает в себя компонент 1210 политики синхронизации и сервер 1212 процессов, который включает в себя компонент 1214 технологических процессов и компонент 1216 правил.

В работе данные, которые должны использоваться конкретным составным приложением, могут постоянно находиться во многих местах, некоторые из которых иллюстрируются источниками 1208 данных. Однако обычно программы предполагают обнаружить данные в одном месте, например на локальном вычислительном устройстве. В проиллюстрированном и описанном варианте осуществления к данным можно обращаться из некоторого количества разных мест (то есть источников 1208 данных), переработанных посредством компонента 1210 политики синхронизации в центральное расположение, называемое метабазой 1206. Метабазы образуют представление данных, которое ожидает увидеть приложение, и компонент 1210 политики синхронизации отвечает за обработку данных из различных источников и размещение данных в виде, который ожидает увидеть приложение. Если данные в подходящем виде, то приложение, чьи составные части постоянно находятся в репозитории 1204, может оперировать данными в метабазе 1206.

Как только приложение поработало над данными в метабазе, они могут быть сброшены обратно в соответствующий источник данных. Компонент 1210 политики синхронизации совместно с его сервером 1212 процессов и ассоциированными компонентами 1214, 1216 технологических процессов и правил работают вместе, чтобы гарантировать, что данные синхронизируются и остаются синхронизированными. Как только данные синхронизируются, они могут быть принудительно отправлены обратно в соответствующий источник (источники) данных. Относительно компонента 1206 метабазы рассмотрим следующее. В вышеупомянутом сценарии сверки (то есть в первой из упомянутых областей деятельности) метабаза образует представление данных, которое является сочетанием всех данных во всех выверяемых системах. Политика сверки обычно рассматривается в понятиях схемы метабазы и исходных источников. В сценарии унифицированного представления (то есть во второй из упомянутых областей деятельности) метабаза образует представление, которое важно для приложения - то есть определенное подмножество данных во всех окружающих хранилищах, которое относится к определенному приложению.

В одном или нескольких вариантах осуществления часть программы, которая выполняется, может включать в себя части, которые выполняются вычислительными устройствами, например сервером процессов, и части, которые выполняются отдельными людьми, используя так называемый процесс "People ready" (букв. "люди - готовы"). Пример процесса People ready мог бы рассматриваться как процесс, который бизнес мог бы обычно выполнять. В этом сценарии частью процесса People ready могло бы быть представление конкретного интерфейса пользователя посредством процесса интерфейса пользователя, который позволяет личности выполнять часть работы. Например, если конкретный процесс включает в себя три этапа, A→B→C, в полностью автоматизированном процессе, то A и B и C задавались бы с помощью кода, правил или технологического процесса. В процессе People ready возможно, что B отправляет письмо человеку, запрашивающему копию отчета, а C вставляет задачу в Outlook®, запрашивающую у менеджера прочитать отчет и утвердить его. Фиг.13 иллюстрирует примерное окружение служб обеспечения жизненного цикла приложения в целом по ссылке 1300. Здесь окружение 1300 включает в себя исполнительный компонент 1302, репозиторий 1304, аналитический компонент 1306, приложение 1308 и ряд средств 1310 проектирования или разработки, которые вводят данные в репозиторий.

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

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

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

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

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

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

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

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

Обратим теперь внимание на цикл между исполнительным компонентом 1302, приложением 1308, аналитическим компонентом 1306 и репозиторием 1304. Одной характерной причиной для цикла является то, что существует понятие соглашения об уровне обслуживания, которое задает то, как и когда приложение должно отвечать на запросы. Например, аналитический компонент 1306 может запрашиваться, чтобы выяснить, насколько быстро приложение 1308 отвечает на запросы или выполняет некоторую другую задачу. Если производительность приложения не является подходящей или иным образом не удовлетворяет некоторым показателям производительности, то модель может настраиваться в репозитории, чтобы приложение могло соответствовать показателям производительности. Исполнительный компонент 1302 затем может обновить работающую модель, чтобы сделать приложение эффективнее. Таким образом, динамические контуры обратной связи могут добиться целевого поведения и могут гарантировать, что конечные пользователи приложения получают хорошую производительность. В более общем смысле, в дополнение к поддержке федеративного командования и управления исполнительный компонент 1302 также поддерживает федеративный сбор разведывательной информации о приложении. Чтобы собрать сведения о приложении, в репозиторий 1304 может быть добавлена "модель наблюдений" как часть модели распределенных приложений. Исполнительный компонент анализирует модель наблюдений, выясняет, какие данные следует собирать в каждой части приложения и отдает эти запросы драйверам. Драйверы затем выполняют любые задачи, которые используются, чтобы заставить их часть системы собирать подходящие данные.

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

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

Фиг.14 иллюстрирует примерное окружение репозитория в соответствии с одним или несколькими вариантами осуществления, в целом по ссылке 1400. Здесь репозиторий 1304 показан логически помещенным между средствами 1310 разработки и компонентом 1402 служб интеграции. Репозиторий включает в себя информацию о приложении и его производительности, жизненном цикле, требованиях и всю другую важную информацию. По существу, репозиторий 1304 может принимать данные из ряда источников, в целом обозначенных ссылкой 1404. Например, данные приложения могут описываться с использованием ряда разных механизмов, например, указанных по ссылке 1406. Иначе или дополнительно, по ссылке 1408 каталог SQL может быть уместным, если приложение использует таблицы SQL или хранимые процедуры. Иначе или дополнительно, по ссылке 1410 данные приложения могут описываться с использованием ряда систем управления исходным кодом или описаний сторонних производителей по ссылке 1412. Таким образом, средства 1310 разработки обычно имеют первичную связь с репозиторием, а репозиторий имеет первичную связь с другими хранилищами данных. Репозиторий создает федеративное представление по всем этим разным хранилищам данных, используя компонент службы интеграции.

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

Фиг.15 иллюстрирует примерное окружение исполнения в соответствии с одним вариантом осуществления, в целом по ссылке 1500. Окружение 1500 в этом примере включает в себя исполнительную систему 1502, логически помещенную между репозиторием 1504 и сервисной шиной 1506.

В одном или нескольких вариантах осуществления исполнительная система 1502 объединяет хосты или контейнеры, такие как SharePoint, IIS/WAS, BizTalk и SQL Server, чтобы предоставить ограниченные областью определения приложения (то есть всем приложением) командование, управление и мониторинг для распределенных приложений. Среди функций, которые выполняет исполнительная система 1502, в качестве примера, а не ограничения, находится перевод запросов командования и управления в области всей модели в запросы командования и управления в контейнерах, в которых будут работать части распределенной модели. В проиллюстрированном и описанном варианте осуществления этот перевод управляется технологическими процессами, реализующими настраиваемые бизнес-процессы. К тому же, исполнительная система 1502 преобразует модели наблюдений, заданные на области целых моделей, в запросы, которые отдельные контейнеры формируют определенные виды событий. Так как эти события формируются в контейнерах, исполнительная система преобразует их обратно в стандартный формат и отправляет их через сервисную шину 1506 в производительное хранилище, показанное как часть репозитория 1504. Исполнительная система 1502 поддерживает изменения в некоторой части конфигурации параметров работающих моделей в реальном масштабе времени, чтобы приложения могли настраиваться, и модели наблюдений могут изменяться без перезапуска лежащих в основе приложений. С помощью поддержки возможности применять глаголы типа "Развернуть" и "Запустить" к моделям и с помощью агрегирования полученной путем наблюдения информации о моделях исполнительная система объединяет существующие контейнеры и обеспечивает взаимодействие распределенных моделей, работающих на одной системе.

Обращаясь конкретнее к иллюстрации фиг.15, репозиторий 1504 хранит приложения и проверочные утверждения политик, которые являются правилами, которым следует приложение. Репозиторий также включает в себя все ресурсы, которые ассоциируются с приложением, например, это конкретное приложение может работать на этих конкретных восьми компьютерах, четырех SQL-серверах и двух веб-серверах. К этим приложениям, ресурсам и другие данным в репозитории можно обращаться некоторым количеством разных способов. Например, доступ может происходить через портал, через консоль управления (ММС) или через Quadrant (или некоторое другое средство моделирования, запланированное непосредственно в репозитории). Соответственно, исполнительная система является сущностью, которая обращается к приложениям из репозитория и уточняет, разворачивает, запускает, останавливает, управляет версиями и выполняет другие функции по отношению к приложениям.

В работе исполнительная система 1502 состоит из некоторого количества разных служб, каждая из которых может работать на разных компьютерах. В этом конкретном примере развернутая модель приложения может быть приложением Sharepoint с процессом, администрируемым сервером процессов, и базой данных SQL, как проиллюстрировано. Исполнительная система обычно берет модель приложения и выполняет некоторые уточнения, например выяснение, какие конкретные SQL-серверы и серверы процессов собираются использовать и т.п. После выяснения, какие конкретные серверы или службы нужно использовать, исполнительная система знает, какие драйверы использовать для развертывания, и может затем развернуть модель. Функциональные возможности управления драйверами в исполнительной системе обеспечивают исполнительную систему возможностью иметь дело со всеми разными местами, в которых может работать приложение, например Sharepoint, SQL, COM+, SQL, Windows Shell и т.п.

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

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

Фиг.16 иллюстрирует примерное окружение в соответствии с одним или несколькими вариантами осуществления, в целом по ссылке 1600. Здесь одинаковые номера из варианта осуществления фиг.15 использованы в необходимых случаях для изображения одинаковых компонентов. В дополнение к включению исполнительной системы 1502, репозитория 1504 и сервисной шины 1506 окружение 1600 включает в себя аналитический компонент 1602, который содержит то, что может считаться частью аналитических служб системы.

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

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

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

Компонент инструментария

В одном или нескольких вариантах осуществления компонент 110 инструментария (фиг.1) включает в себя различный инструментарий, примеры которого включают в себя инструмент на базе кода, например компонент 132 Visual Studio, инструмент на базе модели, например компонент 134 Quadrant, и инструмент управления предприятием, например компонент 136 System Center.

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

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

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

Примерная система

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

Вычислительное устройство 1700 включает в себя один или несколько процессоров или модулей 1702 обработки, одно или несколько запоминающих устройств и/или компонентов 1704 хранения, одно или несколько устройств 1706 ввода/вывода (I/O) и шину 1708, которая позволяет различным компонентам и устройствам обмениваться информацией друг с другом. Шина 1708 представляет один или несколько любых типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессор или локальную шину, использующие любую из ряда шинных архитектур. Шина 1708 может включать в себя проводные и/или беспроводные шины.

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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