Глобальная XML архитектура Microsoft® (Microsoft® Global XML Architecture (GXA)) – это оболочка протокола, разработанная для обеспечения совместимой модели построения протоколов уровня инфраструктуры для Web сервисов и приложений. Помимо этой основной оболочки протокола, GXA определяет семейство подключаемых протоколов инфраструктуры, которые обеспечивают приложения обычными сервисами, такими как безопасность, надежность и многостороннее соглашение. Этот документ описывает основные принципы разработки GXA и предоставляет руководство для понимания того, как составляются отдельные протоколы GXA-инфраструктуры для обеспечения цельной платформы для Web сервисов и приложений.

Основная предпосылка появления GXA — разработчики приложений не хотят перестраивать всю платформу для каждого приложения. Эта предпосылка доминирует в модели одномашинной разработки, при которой 95% программистов мира пишут приложения, использующие платформу, созданную оставшимися 5%. Традиционный мир одномашинной разработки программного обеспечения десятилетиями пытался формализовать технологии разбиения на модули, которые делают разделение приложения и платформы ясным и легким для понимания.

Мир протоколов связи тоже придумал свои технологии разбиения на модули, из которых наиболее известна концепция многоуровневого представления протоколов, проиллюстрированная семиуровневым стеком протоколов OSI. Другие технологии разбиения на модули просуществовали в исследовательском сообществе лишь некоторое время; но некоторые из них известны подавляющему большинству программистов. Основной целью разработки GXA является: (а) предоставление более формальной модели для организации модульного принципа протокола и (b) создание семейства протоколов уровня платформы для того, чтобы разработчики приложений применяли их в своих Web сервисах и приложениях. Точно так же, как операционная система предоставляет общеиспользуемые средства, такие как распределение потоков, проверки доступа и управление памятью, GXA предоставляет ряд общеиспользуемых средств, которые необходимы многим Web сервисам и приложениям.

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

Поскольку, в конечном счете, GXA - семейство проводных протоколов, нет необходимости использовать концептуальную модель GXA в приложениях, которые взаимодействуют с Web-сервисами, основанными на GXA. Поскольку GXA построен на базе XML и SOAP, любой Perl-хакер может состряпать необходимые сообщения, чтобы взаимодействовать с поддерживающим GXA Web-сервисом; поэтому GXA выступает как фундаментальное основание для следующего поколения инструментальных средств Microsoft XML Web-сервисов, оболочек и приложений.

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

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

GXA предоставляет оболочку для компоновки протоколов инфраструктуры с протоколами приложений. Эта оболочка скептически относится к базовым транспортным протоколам, протоколам кадрирования и маршаллинга. GXA определен в терминах SOAP, который является основным протоколом для Web-сервисов. Это не запрещает использовать GXA-протоколы в других контекстах; скорее, определение связывания для GXA-протоколов не на базе SOAP не свойственно GXA.

Начиная с самых ранних своих версий, датируемых 1998 годом, SOAP сосредоточился на обеспечении механизма смешивания протоколов приложения и инфраструктуры. Более того, W3C спецификация SOAP 1.2 (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnsoapspec/html/soapspecindex.asp) явно отделяет эти механизмы от других аспектов протокола, таких как кодирование данных и HTTP-привязок. Часть I спецификации SOAP 1.2 представляет модель обработки сообщений, которая является сутью архитектуры GXA.

SOAP-сообщения – это XML-документы, которые придерживаются предопределенной схемы. Эта схема определяет соглашение о разделении, по которому основной полезный груз сообщения (называемый телом) может быть дополнен вспомогательными частями XML, которые называют заголовками (header). Рассмотрите следующее SOAP 1.1 сообщение:

<soap:Envelope 
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:ns1="http://platforms-r-us.org/profiles"
  xmlns:ns2="http://the-platform-co.com/qos/priority"
  xmlns:ns3="urn:schemas-acme-com:pvr.v1"
>
  <soap:Header>
    <ns1:preferences>
       <genre>Noir</genre>
       <format>WMV</format>
    </ns1:preferences>
    <ns2:priority>
      <level>low</level>
    </ns2:priority>
  </soap:Header>
  <soap:Body>
    <ns3:Record>
      <channel>11</channel>
      <start>2003-01-11T08:00:00-8:00</start>
      <duration>P30M</duration>
    </ns3:Record>
  </soap:Body>
</soap:Envelope>

В этом примере элемент Record – это тело сообщения. Элементы preferences и priority – это отдельные заголовки сообщения. Говоря на языке GXA, SOAP-тело передает информацию, относящуюся к протоколу приложения; элементы заголовка передают информацию, которая является частью протокола инфраструктуры.

Заголовки SOAP строго типизированы и роль каждого из них определена именем его элемента, определяемым пространством имен. Чтобы со временем можно было бы представить новые типы заголовков, SOAP обеспечивает явную поддержку для определения заголовков как необязательных или обязательных с помощью атрибута soap:mustUnderstand. Заголовки отмечаются как обязательные, чтобы показать, что все сообщение не может быть правильно (или безопасно) интерпретировано без обработки обязательного заголовка. Чтобы показать, что был встречен неизвестный заголовок, SOAP предоставляет хорошо знакомый код ошибки. Необязательные заголовки могут быть благополучно проигнорированы программным обеспечением, которое не распознает тип элемента заголовка.

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

<soap:Envelope 
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:ns1="http://platforms-r-us.org/profiles"
  xmlns:ns2="http://the-platform-co.com/qos/priority"
  xmlns:ns3="urn:schemas-acme-com:pvr.v1"
>
  <soap:Header>
    <ns1:preferences soap:mustUnderstand='1'>
       <genre>Noir</genre>
       <format>WMV</format>
    </ns1:preferences>
    <ns2:priority>
      <level>low</level>
    </ns2:priority>
  </soap:Header>
  <soap:Body>
    <ns3:Record>
      <channel>11</channel>
      <start>2003-01-11T08:00:00-8:00</start>
      <duration>P30M</duration>
    </ns3:Record>
  </soap:Body>
</soap:Envelope>

В этом примере заголовок preferences — это обязательный заголовок, поскольку он содержит атрибут soap:mustUnderstand, значение которого "1". От получателя этого сообщения требуется распознать этот заголовок и правильно обработать его в соответствие с протоколом этого заголовка. Если заголовок не может быть обработан по причине того, что у получателя нет предварительных сведений о заголовке, тогда должно быть возвращено SOAP-сообщение об ошибке.

Для многих SOAP-заголовков имени элемента, определяемого пространством имен, достаточно для передачи намерения отправителя. При некоторых обстоятельствах нужен дополнительный идентификатор, чтобы определить, какой именно участок программы должен обрабатывать сообщение. Вместо того чтобы вставлять этот идентификатор в тип каждого заголовка, которому нужна эта функциональная возможность, SOAP формализирует эту идею через атрибут soap:role (в SOAP/1.1 soap:actor). Элементы SOAP-заголовка могут иметь атрибут soap:role, значением которого является просто URI. То как этот URI обрабатывается, зависит от узла, обрабатывающего сообщение.

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

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

В частности, основные части инфраструктуры GXA (маршрутизация, безопасность) предполагают, что введение централизованного управления невозможно. Напротив, наличие централизованного управления рассматривается скорее как исключение, чем как правило – децентрализация принимается по умолчанию. Чтобы обеспечить работу этого децентрализованного подхода без порождения хаоса, GXA основывается на иерархической природе механизма URI, что позволяет выступать в роли "объединителя" неравноправных, автономных организаций. Этот подход использует существующее пространство имен, на котором основаны сегодняшние Internet и XML, и которое можно увидеть в GXA-архитектуре маршрутизации и ее инфраструктуре политик.

Модульный принцип: Ключом к успеху SOAP был его модульный принцип. Вместо того, чтобы пытаться определить весь набор протоколов, SOAP создал маленькую, но важную нишу (обработку XML-сообщений). Этот модульный принцип был неявен в проекте SOAP и был сделан явным в SOAP/1.1. Модульность SOAP обеспечила возможность применять произвольные транспортные протоколы (например, TCP, HTTP, SMTP), некоторых из которых не существовало на этапе разработки SOAP (например, BEEP, Jabber).

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

Способность фокусироваться GXA-протоколов позволяет им использоваться в качестве строительных блоков. Компонуемость позволяет комбинировать ортогональные GXA-протоколы (например, WS-Security (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-security.asp), WS-Routing (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-routing.asp)) в одно сообщение. В отличие от больших, монолитных протоколов, GXA может применяться по частям или совместно. Если вашему приложению не нужен конкретный GXA-протокол, имеет смысл не использовать его, при этом используя другие части архитектуры.

Свойственные GXA модульность и компонуемость можно сделать управляемыми путем использования расширенных форматов метаданных, которые выражают возможности и требования заданных Web-сервисов. Все вместе эти возможности и требования называются политикой. Спецификация WS-Policy, упомянутое в разделе Безопасность в мире Web-сервисов: предлагаемые архитектура и руководство (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnwssecur/html/securitywhitepaper.asp) руководство по безопасности Web-сервисов IBM/Microsoft, является одним из примеров политико-ориентированных метаданных. Допуская определение с помощью политики различных аспектов передачи сообщений, приложения способны "поздно связываться" с Web-сервисом. Это свободное соединение достигается путем использования политики конъюнкции, в которой требования и возможности каждой стороны используются для нахождения общей почвы, на которой могут существовать все стороны.

Доказательством существования компонуемости GXA-протоколов является то, что различные GXA-протоколы компонуются сами с собой. Например, когда получены обновления политики маршрутизации WS-Referral (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-referral.asp), как получатель знает, можно ли доверять выражению политики? Вместо того чтобы вводить механизм обеспечения безопасности для каждой отдельной маршрутизации, WS-Referral просто предоставляет систему безопасности уровня сообщения внешнему протоколу, скорее всего WS-Security.

Модель данных на базе XML: поскольку GXA основывается на SOAP, GXA-протоколы определены в терминах модели данных для XML. Преимуществом этой модели данных (называемой Информационное множество XML или Infoset (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnxml/html/xmlinfoset.asp)) является широкая поддержка промышленностью, как на основе платформы, так и инструментальной поддержки.

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

Нейтральность по отношению к механизму транспортировки: GXA полностью определен на уровне обмена SOAP-сообщениями. В то время как HTTP доказал свою крайнюю полезность в качестве транспортного протокола для построения XML Web-сервисов, GXA не полагается ни на синтаксис, ни на семантику HTTP. С этой стороны, GXA-протоколы (как и сам SOAP) разработаны для работы на уровне сообщения независимо от лежащего в основе транспортного протокола.

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

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

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

Настраиваемая под приложение виртуальная сеть: Фундаментальным значением GXA является то, что он предоставляет виртуальную сеть через произвольные транспорты и протоколы сети. GXA-протокол, который обеспечивает эту "двойственность Web-сервиса" - WS-Routing (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-routing.asp). WS-Routing абстрагируется от протокол-специфической адресации и нестандартной маршрутизации, схемы адресации на базе URI. WS-Routing, позволяя сообщениям проходить через один или более маршрутных узлов, прежде чем они достигнут конечного получателя сообщения, использует концепцию "посредничества SOAP", как определено SOAP/1.2. Поскольку WS-Routing работает через произвольные транспорты, каждая пересылка может использовать различные способы транспортировки, что обеспечивает возможность связываться двум конечным точкам, даже если они не имеют общего транспортного протокола.

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

Заманчиво посмотреть на виртуализацию GXA-сети и спросить: "Почему бы просто не использовать TCP/IP?". Основной причиной является то, что исключительно сложно реализовывать подстраивающиеся под приложение оптимизации в большинстве коммерческих TCP/IP стеков. Выражая сетевой протокол в терминах XML, становится проще строить подстраиваемую под приложение инфраструктуру (например, маршрутизаторы, шлюзы, мосты), которые используют существующие на базе XML инструментальные средства и технологии. Кроме того, поскольку новые алгоритмы маршрутизации или эвристические правила для повторной передачи при использовании очень доступных инструментальных средств могут быть реализованы в коде пользовательского режима, новинки протоколов больше не нуждаются в низкоуровневом изменения ядра.

Система безопасности, ориентированная на сообщение: как только SOAP формализовал нотацию посредничества, больше не разумно полагаться на безопасность транспортного уровня. Поскольку посреднику может понадобиться обработать сообщение, прежде чем отправить его следующему посреднику (или конечному получателю), система безопасности Web-сервиса должна явно знать "SOAP-ность", лежащую в основе сообщения. Эта осведомленность обеспечивается WS-Security (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-security.asp), основным протоколом безопасности GXA.

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

WS-Security не предоставляет определенного формата для маркера доступа. Хотя, определенные форматы поддерживаются через элемент расширяемости в заголовке безопасности. WS-Security предопределяет формат элемента для нескольких широко используемых протоколов (например, X509, Kerberos).

Маркер доступа, который появляется в заголовке WS-Security, используется (по крайней мере) для двух целей: подписания и изоляции. WS-Security поддерживает подписанные и изолированные части SOAP-сообщения. Подписание сообщения гарантирует то, (а) что отправитель действительно является обработчиком маркера доступа и (b) что подписанные части сообщения не были подделаны. Изолирование сообщения кодирует содержимое сообщения с помощью ключа, который понимают только отправитель и получатель. WS-Security просто предоставляет оболочку для подписания и изолирования и подчиняется определенному извне протоколу, таким как XML Signature и XML Encryption для действующих алгоритмов. Это позволяет WS-Security адаптироваться к новым алгоритмам по мере их разработки.

Богатая поддержка интегрированной безопасности: WS-Security (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-security.asp) – базовая спецификация, представляющая минимальные функциональные возможности, необходимые для отправки защищенных сообщений. В разделе Безопасность в мире Web-сервисов: предлагаемая архитектура и руководство (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnwssecur/html/securitywhitepaper.asp) изложен ряд будущих связанных с обеспечением безопасности протоколов, которые дополнят картину. WS-Trust определит протоколы для создания маркеров доступа и управления доверительными отношениями. WS-Privacy предоставит оболочку для создания выражений о требованиях и предпочтениях обеспечения конфиденциальности информации. WS-Authorization обеспечит механизмы для распознавания требований сервиса к гарантиям/привилегиям. WS-Federation определит протоколы, необходимые для посреднических доверительных отношений между автономными организациями и технологиями аутентификации. WS-SecureConversation обеспечит протокол для установления безопасного контекста связи, включая установление безопасного сеансового ключа, подходящего для изолирования содержимого сообщения. И, наконец, WS-Policy предоставит оболочку для универсального исследования возможностей и требований сервиса.

Распределенное соглашение: С самого первого дня существования SOAP пользователи желали знать, какую роль будут играть транзакции в мире Web-сервисов. Чтобы отвечать нуждам различных приложений, Microsoft определяет инфраструктуру для построения основанных на GXA протоколов распределенного соглашения. Эта инфраструктура не устанавливает определенного протокола реализации соглашения (например, двухфазной фиксации); она просто определяет общую оболочку для установления взаимного интереса различными сторонами, в целях способствования согласованной работе.

Всеобъемлющие метаданные и обнаружение (discovery): GXA предполагает мир, в котором метаданные высокоточны и повсеместны. С этой целью Microsoft в данный момент разрабатывает на базе XML инфраструктуру метаданных, которая позволит произвольным операторам состоять из различных сущностей, которые составляют приложение Web-сервиса. Эта инфраструктура используется для выражения возможностей, предпочтений и требований, предъявляемым к конечным точкам и сообщениям. WS-Referral (http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-referral.asp) – это первое приложение этой инфраструктуры, и готовящиеся к выходу спецификации будут распространять роль метаданных на другие предметные области.

GXA – это семейство протоколов уровня инфраструктуры, которые обогащают современные Web-сервисы и приложения. Отдельные протоколы в GXA решают определенные, узкие проблемы и могут сочетаться друг с другом, чтобы обеспечить связную платформу. Первая волна GXA-протоколов (WS-Routing, WS-Security) предлагает подстраиваемый под приложение сетевой уровень, который может быть гарантированно независимым от базового способа транспортировки. Последующие GXA-протоколы будут дополнять эту сеть возможностями поддержки надежной доставки сообщений, координирования транзакций и всеобъемлющих метаданных и обнаружения.