Платформа составных приложений на базе модели

Платформа составных приложений на базе модели

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

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

Фиг.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, то предоставляется доступ.

По меньшей мере в некоторых вариантах осуществления может происходить другой уровень рекурсии, в кот