Введение в Microsoft® .NET Services для разработчиков

.Инфраструктура NET в облаке

, Аарон Сконнард Pluralsight

2009Май

Все приведенные здесь сведения и фрагменты кода касаются CTP- .версии NET Services, 2009 .вышедшей вмарте года

Содержание

Аннотация..........................................................................................................................................4

Обзор платформы Azure Services Platform.........................................................................................4

Windows® Azure™...................................................................................................................................5

Microsoft® .NET Services.........................................................................................................................5

Microsoft® SQL Services..........................................................................................................................6

Дополнительные сервисы.....................................................................................................................7

Разработка на платформе Azure™ Services Platform............................................................................7

Введение в Microsoft® .NET Services...................................................................................................9

Обзор .NET Services................................................................................................................................9

Как начать работу с .NET Services........................................................................................................10

Создание собственного первого решения.........................................................................................13

Управление учетными данными своего решения.............................................................................16

Примеры, предоставляемые в .NET Services SDK..............................................................................16

Microsoft® .NET Service Bus...............................................................................................................17

Возможность подключения с ретрансляцией...................................................................................19

Возможность прямого подключения.................................................................................................20

Адреса ретрансляции и управление доступом..................................................................................21

Реестр сервиса.....................................................................................................................................22

Очереди и маршрутизаторы...............................................................................................................23

Интеграция с WCF................................................................................................................................25

Простой пример .NET Service Bus........................................................................................................26

Microsoft®.NET Access Control Service...............................................................................................30

Идентификация на базе утверждений...............................................................................................31

Преимущество единой регистрации..................................................................................................32

Портал администрирования...............................................................................................................32

Простой пример .NET Access Control Service......................................................................................33

Microsoft® Workflow Service.............................................................................................................39

Размещение рабочего процесса в облаке.........................................................................................39

Размещение и хранение в облаке......................................................................................................39

Проектирование рабочих процессов для облака..............................................................................40

Действия в облаке...............................................................................................................................41

Простой пример сервиса .NET Workflow Service................................................................................41

Обзор................................................................................................................................................45

Заключение......................................................................................................................................47

Дополнительные ресурсы................................................................................................................47

Пакеты документов по Microsoft® .NET Services................................................................................47

Ресурсы Microsoft® .NET Services........................................................................................................48

Об авторе..........................................................................................................................................48

Благодарности..................................................................................................................................48

Аннотация

Этот документ открывает серию официальных документов, посвященных Microsoft® .NET Services, основной части Azure™ Services Platform. Microsoft® .NET Services предлагает ряд ориентированных на разработчиков стандартных блоков сервисов, обычно используемых приложениями в облаке и работающими с облаком приложениями. Данный обзорный документ представляет Microsoft® .NET Services, все его стандартные блоки сервисов и их компоновку. Более детально каждый из сервисов обсуждается в остальных документах данной серии (см. Дополнительные ресурсы).

Обзор платформы Azure Services Platform

Платформа Azure™ Services Platform создана с целью радикально изменить подход архитекторов и разработчиков к построению и управлению приложениями. Azure™ Services Platform (рис. 1) обеспечивает среду обработки данных в Интернет-облаке для выполнения приложений и хранения данных в информационных центрах Microsoft по всему миру. Во многих отношениях эту платформу можно рассматривать как Windows® в облаке.

Рис. 1: Платформа сервисов Azure

В основе Azure™ Services Platform лежит операционная система в облаке Windows®Azure™, которую дополняют несколько многоуровневых стандартных блоков сервисов, как показано на рис. 1. Эту новую вычислительную платформу в облаке от Microsoft можно использовать для размещения совершенно новых приложений или отдельных сервисов, улучшающих существующее локальное программное обеспечение. Выбор исключительно за вами.

Windows® Azure™

Windows®Azure™ предоставляет вычислительную среду облака, которая находится в информационных центрах Microsoft, для создания, развертывания, управления и распределения (масштабирования) приложений и сервисов в Интернете. Windows®Azure™ обеспечивает две основные области функциональности: вычисления (например, выполнение приложения) и хранение (например, хранение данных на диске). Ценность в том, как Windows® Azure™ обеспечивает эти основные возможности, что делает их, теоретически, безграничными. Масштабирование – это просто вопрос конфигурации. С коммерческой точки зрения, Windows® Azure™ избавляет вас от многих дорогостоящих устройств и процессов, связанных с подготовкой к работе, настройкой и управлением физическими серверами и программным обеспечением, выполняющимся на них.

Важно отметить, что сервисы хранения Windows® Azure™ очень просты и высоко масштабируемы. Windows® Azure™ предоставляет базовые сервисы для хранилища BLOB (большой двоичный объект), хранилища очереди и простого хранилища таблиц, но не обеспечивает возможностей реляционной базы данных (например, запроса, поиска, составления отчетов или анализа). Эти расширенные возможности баз данных предоставляет Microsoft® SQL Services.

Как показано на рис. 1, на базе Windows® Azure™ выполняются несколько предлагаемых сервисов, включая Microsoft® .NET Services, Live Services, Microsoft® SQL Services и другие. Данный документ посвящен, в частности, Microsoft® .NET Services, но не лишним будет подробнее описать каждый из этих сервисов в отдельности и то, как они взаимодействуют друг с другом в рамках платформы Azure™ Services Platform.

Microsoft® .NET Services

Microsoft® .NET Services предоставляет ряд сервисов, ориентированных на .NET-разработчиков, и пакет средств разработки (software development kit, SDK) для построения .NET-приложений, предназначенных для выполнения в облаке. Сегодня обеспечивается функциональность, связанная, главным образом, с возможностью подключения приложений, управлением доступом и размещением рабочего процесса.1 На данный момент предлагается три сервиса: Microsoft® .NET Service Bus, Microsoft® .NET Access Control Service и Microsoft® .NET Workflow Service. В некотором роде, Microsoft® .NET Services можно рассматривать как новую инфраструктуру .NET для построения приложений облака, но это среда разработки, полностью основанная на сервисах.

Одной из причин, почему эта среда получила название Microsoft® .NET Services, является то, что она разработана и оптимизирована с ориентированием на .NET-разработчика. Благодаря SDK Microsoft® .NET Services работа с этими размещающимися в облаке сервисами ничем не отличается от написания любого другого .NET-приложения. SDK обеспечивает интегрирование с Windows Communication Foundation (WCF) и Windows Workflow Foundation (WF), что

1Функциональность Microsoft® .NET Services будет расширяться для обеспечения большего числа возможностей .NET Framework в облаке.

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

Хотя Microsoft® .NET Services создана с целью обеспечения первоклассных условий работы для .NET-разработчика, важно отметить, что она основана на протоколах, являющихся промышленными стандартами, что делает возможным интеграцию с ней любой сервисной платформы через стандартные техники REST, SOAP и WS-*. В качестве примера этого сегодня уже доступны для скачивания SDK Java и Ruby для Microsoft® .NET Services.

Microsoft® SQL Services

Microsoft® SQL Services предоставляют набор ориентированных на данные сервисов, созданных с целью расширения возможностей SQL Server и использования его в облаке как части Azure™ Services Platform. Microsoft® SQL Services, фактически, объединяет семейство сервисов, связанных с Microsoft SQL. Первым сервисом этого семейства является Microsoft® SQL Data Services (SDS), который предлагает все возможности реляционной базы в виде сервиса в рамках Azure™ Services Platform. В будущем сервисов для работы с данными будет больше.

SDS предоставляет все возможности реляционной базы данных, но в виде сервиса в облаке. Он включает таблицы, хранимые процедуры, триггеры, представления, индексы и совместимость с Visual Studio .NET, ADO.NET и ODBC. Разработчики смогут подготавливать экземпляры логических серверов и баз данных в облаке и работать с ними, используя те же инструменты и технологии, которые применяются сегодня. Это возможно благодаря тому, что Micrososft® SQL Services поддерживает протокол Tabular Data Stream (TDS), тот же протокол, который использует SQL Server, выполняющийся локально. Таким образом, для работы с экземплярами Microsoft® SQL Services, выполняющимися в облаке, разработчики могут использовать любой совместимый с TDS инструмент или технологию. В итоге, большинству разработчиков понадобится лишь обновить используемые строки подключения так, чтобы они указывали на базы данных Microsoft® SQL Services.

Live Services обеспечивает набор ориентированных на пользователя сервисов, направленных, главным образом, на социальные приложения и взаимодействия, а также среду программирования, упрощающую разработку этих приложений. В частности, Live Services включает Mesh Services, Identity Services, Directory Services, User-Data Storage Services, Communication and Presence Services, Search Services и Geospatial Services.

Live Framework является основанной на стандартах средой разработки для взаимодействия со всеми Live Services через единый протокол/интерфейс. В Live Framework объединены REST, Atom и AtomPub, что позволяет интегрироваться с Live Services через обычные методы программирования HTTP/XML. Также она поставляется с удобным клиентским SDK для .NET-разработчиков и насыщенной клиентской средой выполнения, которая обеспечивает встроенные возможности синхронизации, а также поддержку работы в сети и в автономном режиме.

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

Дополнительные сервисыВ дополнение к основным сервисам (.NET, SQL, and Live) Microsoft активно работает, чтобы предложить в будущем некоторые специальные сервисы. Одним из таких предложений является Microsoft® SharePoint Services. Он будет предоставлять ряд стандартных блоков сервисов SharePoint, которые можно включать в собственные приложения. Еще один пример – Microsoft® Dynamics CRM Services, набор стандартных блоков сервисов Microsoft® Dynamics CRM, размещаемых в облаке. В обоих случаях разработчики смогут продолжать использовать Visual Studio для создания приложений для Azure™ Services Platform. Оба предложения находятся в стадии разработки и подготовки к выпуску начальной CTP-версии каждой из технологий.

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

Разработка на платформе Azure™ Services Platform

Итак, Azure™ Services Platform – это платформа для разработки приложений, ориентированная на разработчиков. Одним из наиболее полезных аспектов Azure™ Services Platform является то, что при работе с ней используются навыки, уже имеющиеся у разработчиков Microsoft. Создавая приложения для Azure™ Services Platform, разработчики могут писать традиционный .NET-код в Visual Studio и использовать свой опыт работы с Windows Communication Foundation, Windows Workflow Foundation, Windows SharePoint, Windows Live и SQL Server.

Разработка на Azure™ очень схожа с опытом разработки на платформе Microsoft .NET. Разница заключается лишь в техниках развертывания, размещения, масштабирования и управления новыми программными продуктами в облаке. Тот факт, что Azure™ Services Platform успешно совмещается с уже существующей экосистемой .NET, дает Microsoft значительное конкурентное преимущество в обработке данных в облаке.

При построении комплексного работающего в облаке приложения для Azure™ Services Platform, скорее всего, придется использовать многие, если не все, описанные выше предлагаемые сервисы. Сервисы Microsoft® .NET Services обеспечат возможность подключения и безопасность, Microsoft® SQL Services – хранение и извлечение данных, и Live Services – функции синхронизации на базе Mesh. Огромную ценность представляет возможность сочетания этих предлагаемых сервисов в завершенные приложения. Детальное представление Azure™ Services Platform и рассмотренных сервисов можно увидеть на рис. 2.

Your applications Ваши приложенияService Bus Сервисная шинаWorkflow Рабочий процесс

Access Control Управление доступомDatabase База данныхAnalytics АнализReporting Составление отчетовIdentity ИдентификацияContacts КонтактыDevices Устройства

Compute ВычислениеStorage ХранениеManage Управление

Рис. 2: Детальное представление платформы Azure Services Platform

Компания Microsoft сама активно использует эти сервисы для создания конечных пользовательских приложений на платформе Azure™ Services Platform. Windows Live, Microsoft® Office Live, Microsoft® Exchange Online, Microsoft® SharePoint Online и Microsoft® Dynamics CRM Online (вернитесь к рис. 1), – все это примеры таких готовых конечных пользовательских приложений.

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

Введение в Microsoft® .NET Services

Являясь разработчиком на Microsoft .NET, переходящим к Azure™ Services Platform, вы захотите поближе познакомиться с предложением Microsoft® .NET Services, которое с данного момента в данном документе мы будем называть просто «.NET Services». Причина проста: .NET Services предоставляют основные стандартные блоки, которые понадобятся при построении приложений в облаке и работающих с облаком для Azure™ Services Platform. Далее в данном документе будет подробно рассмотрен представленный на рис. 2 блок .NET Services.

.Обзор NET Services

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

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

Microsoft ® . NET Service Bus : предоставляет сетевую инфраструктуру для соединения приложений через Интернет с использованием разнообразных шаблонов обмена сообщениями способом, обеспечивающим возможность прохождения межсетевых экранов и NAT-устройств без нарушения безопасности, предоставляемой этими устройствами.

Microsoft ® . NET Access Control Service : обеспечивает управление доступом в облаке на основании утверждений. Он включает механизм преобразования утверждений, который объединяется с поставщиками удостоверений, такими как Active Directory и Windows Live ID (WLID). В будущих версиях будет реализована интеграция с любыми поставщиками удостоверений.

Microsoft ® . NET Workflow Services : предоставляет инфраструктуру для размещения и управления рабочими процессами WF, уделяя основной внимание взаимодействию через сообщения посредством .NET Service Bus. Поставляется с новыми действиями WF и инструментами для размещения и управления экземплярами рабочего процесса.

Данные новые сервисы можно рассматривать как .NET-инфраструктуру сервисов для облака. Все они доступны через открытые протоколы и стандарты, включая REST, SOAP, Atom/AtomPub и WS-*. Это означает, что разработчики на любой платформе могут интегрироваться с этими сервисами.

Однако, в попытке сделать все максимально привычным для .NET-разработчиков, Microsoft также предоставляет .NET Services SDK, который обеспечивает первоклассные условия для .NET-разработчика и скрывает многие сложные моменты работы с сервисами.

.NET Services SDK позволяет разработчикам использовать имеющийся опыт .NET-разработки, в частности в областях WCF и WF, через применение новых расширений инфраструктуры SDK (например, новых привязок, каналов и действия). SDK также включает поддержку инструментов Visual Studio для интеграции с порталом Azure™ Services Portal. Кроме .NET Services SDK, сегодня партнеры Microsoft предлагают Java и Ruby SDK (ссылки можно найти в разделе «Дополнительные ресурсы»).

.Как начать работу с NET Services

Чтобы начать работу с .NET Services, перейдите на портал Azure™ Services Platform по адресу http :// azure . com и щелкните ссылку «Try It Now» (Попробуйте сейчас). Вы перейдете на страницу «Register for Azure Services» (Регистрация для сервисов Azure), представленную на рис. 3. На этой странице даются важные ссылки для скачивания различных SDK, доступа к дополнительным ресурсам и перехода на сайт Microsoft Connect, где можно зарегистрироваться для получения кода приглашения.

Рис. 3: Портал Azure™ Services Platform

Далее потребуется загрузить .NET Services SDK. Обратите внимание, что имеется несколько SDK: один – специально предназначенный для разработки Windows® Azure™; другой – для разработки .NET Services; и остальные – для SQL Data Services и Live Framework. Для воспроизведения примеров, предлагаемых в данной серии документов, понадобится скачать и установить .NET Services SDK.

Скачав .NET Services SDK, просто запустите программу установки, как показано на рис. 4. Тем самым вам будут доступны новые .NET-сборки, которые вместе с некоторыми надстройками Visual Studio помогут начать использование различных функций .NET Services. Приступая к работе с .NET Services, обязательно ознакомьтесь с остальными ресурсами, доступными с этой страницы (демонстрации, видео, практические лабораторные и т.д.), цель которых – сделать процесс обучения более насыщенным и разнообразным. Скачать SDK можно, не создавая учетной записи, но, чтобы использовать сервисы, необходимо зарегистрироваться.

Рис. 4: Запуск установки .NET Services SDK

Чтобы зарегистрироваться на получения учетной записи Azure Services, щелкните показанную выше ссылку «Register for Services» (Регистрация для сервисов). Вам будет предложено зарегистрироваться, используя Windows Live ID (WLID). После этого вы перейдете на сайт Microsoft Connect, где потребуется заполнить регистрационную форму Azure Services CTP. После успешной регистрации на Azure Services CTP, на экране появится страница, представленная на рис. 5.

Рис. 5: Регистрация для Azure Services Platform на сайте Microsoft Connect

Теперь можно вернуться на страницу входа .NET Services (щелкните ссылку «.NET Services Portal», которая показана на рис. 5). Эту страницу можно увидеть на рис. 6.

Рис. 6: Страница входа .NET Services

Теперь, щелкнув «Sign Up» (Войти), вы получаете возможность создавать решение .NET Services. Примечание: в CTP-версии, вышедшей в марте 2009, для создания решения .NET Services больше не требуется код приглашения.

Создание собственного первого решенияДля создания решения необходимо просто ввести уникальное имя решения1, принять условия использования и нажать «Create Solution» (Создать решение). После этого новое решение будет подготовлено и ассоциировано с вашим WLID. Теперь, в любой момент, зарегистрировавшись на портале Azure™ Services Platform, вы имеете возможность управлять решениями, ассоциированными с вашим WLID.

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

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

Рис. 7: Завершение процесса подготовки решения

После успешного создания решения можно приступать к работе с ним на портале Azure™ Services Platform. Зарегистрировавшись под собственным WLID, на странице портала справа вы увидите меню «My Solutions» (Мои решения) (рис. 8). Для работы с конкретным решением необходимо просто выбрать его в меню «My Solutions», после чего вам будет представлена страница, показанная на рис. 9.

По сути, решение – это контейнер верхнего уровня для организации различных ресурсов .NET Services.1 Например, в нем размещаются конечные точки .NET Service Bus, типы и экземпляры рабочих процессов .NET Workflow Service, а также ваши удостоверения .NET Access Control Service и правила преобразования утверждений. Но одним из самых важных аспектов, которым вы захотите управлять после создания собственного решения, являются учетные данные решения.

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

Рис. 8: Управление своими решениями посредством меню «My Solutions»

Рис. 9: Управление отдельным решением

Управление учетными данными своего решенияПароль решения, предоставленный в процессе подготовки, можно изменить на странице «Credential Management» (Управление учетными данными) (просто щелкните ссылку «Solution Credentials» (Учетные данные решения), которую можно видеть на рис. 9). С этой страницы можно также конфигурировать информационные карточки Windows CardSpace, ассоциированные с данным решением, и также любые сертификаты, которые необходимо ассоциировать с решением (рис. 10).

Рис. 10: Управление учетными данными своего решения

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

, .Примеры предоставляемыев NET Services SDK

.NET Services SDK включает ряд интересных примеров, которые иллюстрируют использование различных возможностей, предлагаемых .NET Services. После установки SDK эти примеры можно найти в следующем каталоге: C:\Program Files\Microsoft .NET Services SDK (March 2009 CTP)\Samples.

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

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

Microsoft® .NET Service Bus

Самым распространенным требованием в распределенных приложениях с высоким уровнем масштабируемости является возможность подключения приложений. Обычно интеграция приложений – одна из самых дорогостоящих и хлопотных областей ИТ. Сегодня для этих задач многие организации используют решение Enterprise Service Bus (ESB)1.

.NET Service Bus является основной частью предложения .NET Services. Ее основная задача – сделать шаблон ESB реальностью в Интернете в рамках платформы Azure™ Services Platform. Предоставляемые .NET Service Bus архитектурные характеристики во многом аналогичны предлагаемым типовыми решениями ESB, включая идентификацию и управление доступом, присваивание имен, реестр сервиса и общую среду обмена сообщениями. Основное отличие в области применения. В случае с .NET Service Bus компоненты должны разрабатываться для работы в облаке, в глобальной области Интернета, с обеспечением высокого уровня масштабируемости и интегрируемости. Именно поэтому в прошлом этот предлагаемый сервис назывался Microsoft Internet Service Bus (рис. 11).2

Internet Service Bus позволила бы интегрировать ваш локальный ESB-продукт с вашими собственными выполняющимися в облаке сервисами, с различными сторонними сервисами, предоставляемыми Microsoft или другими производителями (такими как предлагаются в рамках платформы Azure™ Service Platform) и с различными настольными, RIA3 и веб-приложениями, которые могут выполняться на вспомогательных площадках вне межсетевого экрана корпорации.

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

1 Сервисная шина предприятия (прим. переводчика).2 Эта терминология применялась в документации BizTalk Services, но более не является официальным наименованием, используемым Microsoft.3 RIA = Rich Internet Application (Насыщенное Интернет-приложение).

Service Orchestration Взаимодействие сервисовFederated Identity and Access Control Интегрированные идентификация и управления

доступомNaming Присваивание имен

Service Registry Реестр сервисаMessaging Fabric Среда обмена сообщениями

Your Services Собственные сервисыClients Клиенты

Desktop НастольныеWeb Веб

On-Premise ESB Локальная ESBMS/3rd Party Services Сервисы сторонних производителей/MS

Рис. 11: Сервисная шина Интернет

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

Часто компании решают эти проблемы связи, открывая входящие порты межсетевых экранов (что доставляет немало хлопот системным администраторам) или используя различных обходные приемы, такие как динамическая DNS2, сопоставление портов NAT или технологию UPnP3. Все эти методы неустойчивы, трудно управляемы и восприимчивы к угрозам безопасности. Число приложений, для которых требуется такой тип двусторонней связи, постоянно растет. .NET Service Bus призвана удовлетворить эту потребность.1 Network address translation – Преобразование сетевых адресов (прим. переводчика).2 Domain Name System – Служба доменных имен (прим. переводчика).3 Universal Plug and Play – Универсальная автоматическая настройка сетевых устройств (прим. переводчика).

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

Relay Service Сервис ретрансляцииrendezvous address Адрес встречиoutbound connect

bidirectional socketИсходящее соединениедвунаправленный сокет

Msg Сообщение.Sender Отправитель

outbound connect Исходящее соединениеReceiver ПолучательFirewall Межсетевой экран

Dynamic IP Динамический IPРис. 12: Использование сервиса ретрансляции

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

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

Использование ретрансляции .NET Service Bus позволяет реализовывать односторонний обмен сообщениями, обмен сообщениями в режиме запрос/ответ, публикация/подписка (многоадресная рассылка) и даже обмен сообщениями в асинхронном/отсоединенном режиме.

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

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

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

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

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

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

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

Relay Service Сервис ретрансляцииrendezvous address адрес встречи

NAT probing зондирование NAToutbound connect исходящее соединение

Sender ОтправительMsg Сообщение

NAT Traversal Connection Соединение в обход NATReceiver Получатель

Рис. 13: Установление прямого подключения

Адреса ретрансляциии управление доступомОдним из самых важных аспектов для понимания при работе с .NET Service Bus является структурирование адресов встречи для ваших конечных точек .NET Service Bus. При предоставлении конечной точки на базе TCP адреса должны быть структурированы следующим образом:

sb://{решение}.servicebus.windows.net/{определяемый-пользователем}

При предоставлении HTTP-адреса схема протокола «sb» просто заменяется на «http»:

http://{решение}.servicebus.windows.net/{определяемый-пользователем}

Обратите внимание, что имя вашего решения задается как часть адреса. Это делается для того, чтобы различать конечные точки .NET Service Bus, используемые разными решениями. После имени решения вы имеете полное право задать любую иерархию имен URI.

Если вы зарегистрированы на портале Azure™ Services Platform, можете перейти на страницу управления решениями (рис. 9), выбрать одно из решений и затем перейти к разделу управления Сервисной шиной. На этой странице представлена документация, описывающая, как должны быть структурированы адреса для данного решения.

Ретранслятор обеспечивает возможности управления доступом через модель безопасности на базе утверждений и отношение доверия с .NET Access Control Service. Ретранслятор ищет маркер доступа, выпущенный .NET Access Control Service, соответственно которому определяет, должен ли конкретный отправитель или получатель получить право «отправлять» или «слушать» определенный адрес встречи .NET Service Bus.

Прежде чем получатель сможет слушать определенный адрес, он должен получить от .NET Access Control Service маркер доступа, содержащий утверждение «#Listen». Для получения такого маркера он должен будет предоставить .NET Access Control Service свои учетные данные. Отправители тоже должны получить от .NET Access Control Service маркер доступа с утверждением «#Send».

Чтобы получить маркер доступа для ретранслятора .NET Service Bus, отправители и получатели должны будут предоставить учетные данные на .NET Access Control Service. .NET Access Control Service поддерживает разные типы учетных данных, что обсуждается ниже. Поскольку ретранслятор имеет доверительные отношения с .NET Access Control Service, он может читать выпускаемые этим сервисом маркеры доступа и обрабатывать утверждения.

Реестр сервиса.NET Service Bus предоставляет реестр сервиса для публикации и поиска ссылок на конечные точки сервиса в рамках решения. Ссылки на конечные точки могут публиковаться либо как простые URI, либо как конечные ссылки WS-Addressing. Теперь, чтобы получить конечные ссылки решения, необходимо перейти на базовый адрес решения и извлечь канал Atom, содержащий эти сведения.1

Существует два способа публикации конечных ссылок в реестре сервиса. Самый распространенный подход – позволить службе WCF делать это за вас, когда сервис ретрансляции регистрирует слушателей реестра. При создании слушателей сервис ретрансляции автоматически заполняет реестр сервиса конечными ссылками через привязки WCF (и соответствующие каналы), поставляемые с .NET Services SDK. Также можно публиковать конечные ссылки в реестре сервиса вручную через интерфейс AtomPub.1 Это можно сделать программно, просто сформировав HTTP-запрос GET к базовому адресу решения.

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

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

CTP-версия, выпущенная в марте 2009, представляет новые примитивы обмена сообщениями, очереди и марштуризаторы, которые делают возможной поддержку разнообразных дополнительных требований, обычно предъявляемых распределенными приложениями сегодня. Эти новые примитивы являются свидетельством изменения стратегии Microsoft относительно .NET Services Bus и дальнейшего развития. Они являются долговечными (постоянными) и могут существовать независимо от традиционных слушателей .NET Service Bus. Иначе говоря, очереди/машрутизаторы могут существовать даже в случае отсутствия активных слушателей.

Очереди, как предполагает их название, обеспечивают долгосрочную структуру данных с семантикой FIFO. Очередь создается в пространстве имен .NET Service Bus точно так же, как слушатели. Для этого в пространстве имен решения .NET Service Bus просто задается имя очереди, определяется политика очереди и формируется запрос к .NET Service Bus на создание очереди с заданным именем.

Будучи созданными, отправители могут отправлять сообщения в очередь, и получатели могут читать сообщения из очереди, но суть в том, что вовсе не обязательно, чтобы эти отправители и получатели выполнялись одновременно. Отправители могут передавать сообщения в очереди, используя протоколы HTTP(S) или net.tcp, но получатели могут читать сообщения из очереди только с помощью HTTP(S). Также очереди поддерживают принцип выбора с блокировкой (peeks with locks), что гарантирует сохранность сообщений в случае сбоя приложения. Необходимо знать несколько основных ограничений: очереди поддерживают сообщения размером до 64КБ и не поддерживают потоковую передачу.

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

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

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

Router (Distribution: All) Маршрутизатор (Распределение: All)Queue Очередь

Router (Distribution: One) Маршрутизатор (Распределение: One)Service Сервис

Рис. 14: Сочетание очередей и маршрутизаторов

В данном примере политика распределения интерфейсного маршрутизатора – «All». Это означает, что он будет рассылать входящие сообщения всем подписчикам. У этого маршрутизатора два подписчика: очередь и другой маршрутизатор. Очередь просто обеспечивает долговременное хранение поступивших сообщений, в то время как сервис (Сервис А) периодически выбирает их непосредственно из очереди. Обратите внимание, что для второстепенного маршрутизатора задана политика «One», т.е. он будет равномерно распределять входящие сообщения по одному между всеми подписчиками (Сервис B, C и D). Он также мог бы без труда рассылать сообщения всем подписчикам; для этого просто необходимо изменить политику на «All».

Интеграция с WCF

Основная модель программирования для работы с .NET Service Bus на платформе .NET – WCF. .NET Services SDK поступает с набором новых привязок WCF, которые автоматизируют

интеграцию ваших WCF-сервисов и клиентов с сервисом ретрансляции. В большинстве случаев требуется лишь заменить текущую привязку WCF одной из привязок .NET Service Bus.

На рис. 15 перечислены все WCF-привязки .NET Service Bus и стандартные WCF-привязки, которым они соответствуют. Все наиболее широко используемые привязки WCF, такие как BasicHttpBinding, WebHttpBinding, WSHttpBinding и NetTcpBinding, имеют соответствующие привязки .NET Service Bus с очень схожими именами (просто перед «Binding» добавляется слово «Relay»). Лишь некоторые привязки – NetOneWayRelayBinding и NetEventRelayBinding – не имеют соответствующей привязки в WCF.

Стандартная привязка WCF Эквивалентная привязка ретрансляции

BasicHttpBinding BasicHttpRelayBindingWebHttpBinding WebHttpRelayBindingWSHttpBinding WSHttpRelayBindingWS2007HttpBinding WS2007HttpRelayBindingWSHttpContextBinding WSHttpRelayContextBindingWS2007HttpFederationBinding WS2007HttpRelayFederationBindingNetTcpBinding NetTcpRelayBindingNetTcpContextBinding NetTcpRelayContextBindingN/A NetOnewayRelayBindingN/A NetEventRelayBinding

Рис. 15: Привязки WCF

Чтобы использовать .NET Service Bus, при определении конечной точки WCF задается соответствующая привязка ретрансляции (которая обеспечивает искомую семантику возможности подключения и обмена сообщениями) и адрес ретрансляции. Тогда при открытии ServiceHost (для получателя) или ChannelFactory (для клиента) инфраструктура WCF в фоновом режиме берет на себя заботу о связи с ретранслятором, как описывалось выше.

Несмотря на интеграцию с WCF, важно помнить, что .NET Service Bus основывается на открытых Интернет-стандартах, что обеспечивает возможность установления связи между приложениями на разных платформах. И поскольку она построена на платформе Azure™ Services Platform, .NET Service Bus также предоставляет теоретически неограниченные возможности масштабирования.

.Простой пример NET Service Bus

Позвольте представить небольшой пример настройки простого WCF-приложения, для работы с .NET Service Bus. Начнем с контракта и реализации WCF-службы:

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

class Program{ static void Main(string[] args) { Console.WriteLine("**** Receiver ****"); ServiceHost host = new ServiceHost(typeof(HelloServiceBus)); host.Open();

Console.WriteLine("Press [Enter] to exit"); Console.ReadLine();

host.Close(); }}

И начнем со следующего описания конечной точки в конфигурационном файле приложения. Обратите внимание, как конечная точка использует NetTcpBinding и локальный адрес net.tcp://localhost:8080/helloservicebus:

[ServiceContract]public interface IHelloServiceBus{ [OperationContract] string SayHello(string name);}

class HelloServiceBus : IHelloServiceBus{ public string SayHello(string name) { string greeting = string.Format("Hello {0}!", name); Console.WriteLine("Returning: {0}", greeting); return greeting; }}

<configuration> <system.serviceModel> <services> <service name="Microsoft.ServiceBus.Samples.HelloServiceBus"> <endpoint address="net.tcp://localhost:8080/helloservicebus" binding="netTcpBinding" contract="Microsoft.ServiceBus.Samples.IHelloServiceBus" /> </service> </services> </system.serviceModel></configuration>

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

class Program{ static void Main(string[] args) { Console.WriteLine("**** Sender ****"); Console.WriteLine("Press <Enter> to start sending messages."); Console.ReadLine();

ChannelFactory<IHelloServiceBus> channelFactory = new ChannelFactory<IHelloServiceBus>("RelayEndpoint"); IHelloServiceBus channel = channelFactory.CreateChannel();

string response = channel.SayHello(".NET Service Bus"); Console.WriteLine(response);

channelFactory.Close(); }}

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

<configuration> <system.serviceModel> <client> <endpoint address="net.tcp://localhost:8080/helloservicebus" binding="netTcpBinding" contract="Microsoft.ServiceBus.Samples.IHelloService" name="RelayEndpoint" /> </client> </system.serviceModel></configuration>

Если выполнить эти два приложения, в обоих окнах консоли будет выведено «Hello .NET Service Bus!». В данном случае, между клиентским и сервисным приложениями устанавливается прямое TCP-соединение.

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

Чтобы изменить настройку сервиса на прослушивание .NET Service Bus, можно просто заменить привязку NetTcpBinding на привязку NetTcpRelayBinding. При этом также понадобится указать действительный адрес встречи .NET Service Bus для конечной точки. Поскольку я назвал решение «pluralsight», можно использовать адрес sb://pluralsight.servicebus.windows.net/helloservicebus.

Также необходимо предоставить учетные данные, которые докажут сервису ретрансляции, что я имею право слушать адресное пространство данного решения. Эти учетные данные будут представлены .NET Access Control Service для получения маркера для .NET Service Bus. Это можно сделать несколькими способами, но в данном примере просто используем имя пользователя и пароль. Они могут быть заданы в коде или в конфигурационном файле. Воспользуемся вторым подходом и определим имя пользователя и пароль в элементе <transportClientEndpointBehavior>. Ниже представлена полная конфигурация сервиса с поддержкой .NET Service Bus:

<configuration> <system.serviceModel> <services> <service name="Microsoft.ServiceBus.Samples.HelloServiceBus"> <endpoint address= "sb://pluralsight.servicebus.windows.net/helloservicebus" behaviorConfiguration="default" binding="netTcpRelayBinding" contract="Microsoft.ServiceBus.Samples.IHelloServiceBus" /> </service> </services> <behaviors> <endpointBehaviors> <behavior name="default"> <transportClientEndpointBehavior credentialType="UserNamePassword"> <clientCredentials> <userNamePassword userName="[solution-name]" password="[solution-password]" /> </clientCredentials> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors> </system.serviceModel></configuration>

При открытии с этой конфигурацией, хост WCF-сервиса сначала отправит учетные данные клиента на .NET Access Control Service и запросит маркер доступа для прослушивания .NET Service Bus. Затем он установит TCP-соединение с сервисом ретрансляции и предоставит полученный маркер доступа. Если сервису разрешено прослушивать этот адрес (т.е. маркер содержит необходимое

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

Аналогичным образом меняем конфигурацию клиентского приложения. Прежде всего, для конечной точки задаем NetTcpRelayBinding и тот же адрес встречи, на прослушивание которого мы настроили наш сервис. Также необходимо задать учетные данные клиента. Как и сервис, клиенты тоже должны подтверждать свое право на отправку сообщений на определенный адрес .NET Service Bus, запрашивая маркер у .NET Access Control Service. Ниже представлена полная конфигурация клиента:

<configuration> <system.serviceModel> <client> <endpoint address= "sb://pluralsight.servicebus.windows.net/helloservicebus" binding="netTcpRelayBinding" contract="Microsoft.ServiceBus.Samples.IHelloServiceBus" behaviorConfiguration="default" name="RelayEndpoint" /> </client> <behaviors> <endpointBehaviors> <behavior name="default"> <transportClientEndpointBehavior credentialType="UserNamePassword"> <clientCredentials> <userNamePassword userName="[solution-name]" password="[solution-password]" /> </clientCredentials> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors> </system.serviceModel></configuration>

Внеся все эти изменения, запустим приложение сервиса и затем клиентское приложение. Будет выведен тот же результат, что и ранее, только в этом случае связь ретранслировалась через .NET Service Bus (рис. 16), что позволило преодолеть различные препятствия в сети.

Рис. 16: Пример HelloServiceBus в действии

Более детально и с дополнительными примерами кода .NET Service Bus рассматривается в документе данной серии «Руководство по Microsoft .NET Service Bus для разработчиков» (см. Дополнительные ресурсы).

Microsoft®.NET Access Control Service

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

Идентификация на базе утвержденийMicrosoft® .NET Access Control Service – это сервис в облаке, выполняющий именно эту функцию. Вместо того чтобы создавать собственную базу данных пользовательских учетных записей и ролей, можно предоставить возможность .NET Access Control Service управлять аутентификацией и авторизацией ваших пользователей. .NET Access Control Service использует существующие хранилища учетных записей пользователей, такие как Windows Live ID и Active Directory, а также любые другие хранилища, поддерживающие стандартные протоколы интегрирования. Таким образом, использование единой регистрации для доступа ко всем приложениям становится вполне естественным. Также это обеспечивает централизацию логики аутентификации и управления доступом, что упрощает ваши приложения.

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

Issuing Authority Организация, выдающая удостоверенияSmart Client Смарт-клиент

Application (Web Service) Приложение (веб-сервис)Get WSDL Получить WSDLGet Claims Получить утверждения

Send Claims Отправить утвержденияActive Client (WS-Trust) Активный клиент (WS-Trust)

Рис. 17: Использование идентификации на базе утверждений для веб-сервисов

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

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

Аутентификация пользователей Хранение учетных записей пользователей и паролей Обращение к каталогам предприятия в поисках данных удостоверения пользователя Интеграция с системами удостоверений других платформ или компаний

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

Портал администрирования.NET Access Control Service реализовывает идентификацию на базе утверждений в рамках платформы Azure™ Services Platform. Система администрирования является важной частью .NET Access Control Service.

Рис. 18: Портал ACS

.NET Access Control Service предоставляет портал администрирования (рис. 18) в рамках портала Azure™ Services Portal1. Здесь вы выполняете настройку правил, которые определяют схему выпуска утверждений для различных пользователей, и, в конечном счете, отвечаете на вопрос «Что вы можете делать?».

Портал ACS – замечательное средство для исследования, изучения и начала работы с ACS. И для относительно простых приложений он может быть единственным необходимым инструментом. Но для нетривиальных систем с сотнями или тысячами пользователей и, возможно, таким же количеством правил, использование портала становится громоздким. В таких случаях программный интерфейс – более предпочтительный вариант, поэтому ACS также предоставляет интерфейс AtomPub для программного администрирования. AtomPub – это протокол RESTful, который стандартизует базовые операции CRUD (Create, Retrieve, Update и Delete) для управления удаленными ресурсами. Это открывает совершенно новые возможности.

1 Сервис .NET Access Control Service также включает конечные точки SOAP и REST для программного администрирования, а также ряд .NET-классов, которые упрощают вызов этих конечных точек. Итак, если вам не нравится портал, предоставляемый ACS, или вы желаете реализовать настройки, характерные для определенной предметной области, можно создать собственную консоль администрирования.

.Простой пример NET Access Control Service

Лучший способ разобраться в ACS – увидеть его в действии. Итак, в данном разделе будет последовательно рассмотрен один из примеров, поставляемый в пакете с .NET Services SDK под именем UserNamePasswordCalculatorService.

В этом примере ACS используется для обеспечения безопасности простого WCF-сервиса, предлагающего четыре операции: Add (Сложение), Subtract (Вычитание), Multiply (Умножение) и Divide (Деление). Сервис вычислений в данном примере не интересует имя пользователя, адрес его электронной почты или другие личные данные. Для него важно лишь то, чтобы пользователь, выполняющий запрос на сложение (например), имел право выполнять сложение. Я покажу, как конфигурировать решение в ACS для управления доступом к этим операциям. Чтобы этот пример работал, необходимо сначала создать «решение» в ACS. Более подробно о том, какое это должно быть решение, поговорим немного позже. Пока что просто рассматривайте его как персональный издатель маркеров доступа в облаке. В качестве примера я буду использовать решение под именем «asolution».

Сервис вычислений– это приложение, которое принимает решения, связанные с безопасностью, на основании утверждений, изданных ACS. Таким образом, этот сервис, как любое другое работающее с утверждениями приложение, должен иметь собственный сертификат X.509, который может использоваться ACS для шифрования маркеров доступа, предоставляемых сервису. В примере предлагается простой тестовый сертификат localhost.cer. Именно его я буду использовать для начала.

В подкаталоге Utils данного примера содержится сертификат и командный файл (installcerts.bat), который устанавливает его в персональное хранилище сертификатов локального компьютера. Я выполнил этот командный файл, чтобы установить localhost.pfx на компьютер, на котором будет выполняться сервис, поскольку сервису потребуется доступ к закрытому ключу для дешифрования маркеров, выпускаемых ACS.

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

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

маркеров)3. Правила, согласно которым ACS должен выпускать утверждения

Итак, я перешел к accesscontrol.windows.net и зарегистрировался. Затем выбрал свое решение («asolution»). Это позволило мне добавить приложение в свое решение, как показано на рис. 19. Обратите внимание, что именно здесь задается имя приложения («Application URL») и его сертификат.

Рис. 19: Добавление приложения в решение ACS

По нажатию кнопки Next (Далее) выполняется переход на страницу правил, на которой я настроил несколько очень простых правил для приложения. Клиентская программа сервиса Calculator для аутентификации в ACS использует имя пользователя и пароль. Как будет показано в данном документе далее, каждое решение ACS имеет пароль, т.е. для аутентификации в ACS имя решения может использоваться как имя пользователя, и его пароль – как пароль. Итак, задавая свои правила, я указываю ACS предоставлять разрешения на сложение, вычитание, умножение и деление только пользователям, предоставившим правильное имя пользователя и пароль решения.

На рис. 20 представлен результирующий набор правил.

Рис. 20: Правила для приложения Calculator

По сути своей, ACS – это механизм преобразования утверждений, и это можно увидеть, взглянув на правила на рис. 20. Все заданные правила ожидают одно и то же входящее утверждение: утверждение «UserName» (Имя пользователя) со значением «asolution», выпущенное ACS. Единственная возможность пользователю получить это утверждение от ACS – предоставить имя решения и соответствующий пароль при запросе маркера доступа. Эти четыре правила гарантируют, что любой пользователь, подтвердивший знание пароля для моего решения, получит четыре утверждения «Action» (Действие). Утверждение «Action» содержит строку, определяющую действие. Это может быть все, что угодно: «foo», «1234» или «Calculator.Divide».

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

public class CalculatorService : ICalculator{ public double Add(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Add"); return n1 + n2; } public double Subtract(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Subtract"); return n1 - n2; } public double Multiply(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Multiply"); return n1 * n2; } public double Divide(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Divide"); return n1 / n2; }}

Рис. 21: Код сервиса Calculator

Чуть ниже будет рассмотрен код вспомогательного метода DemandActionClaim (Утверждение требуемого действия), но, надеюсь, из рис. 21 понятно, что перед выполнением операции выполняется лишь поиск утверждения действия с определенным строковым значением. Если заданное утверждение не найдено, вспомогательный метод формирует исключение «access denied» (в доступе отказано). В конечном счете, если пользователь может подтвердить, что он знает пароль решения, ему будет разрешено выполнять сложение, вычитание, умножение или деление. Если нет, ему будет отказано в доступе ко всем этим операциям.

На рис. 22 представлен вспомогательный метод DemandActionClaim. Возможно, вы не знаете этого, но WCF создавался с учетом утверждений. Видите, как OperationContext (Контекст операции) предоставляет доступ к ряду наборов утверждений? Каждый набор утверждений представляет маркер доступа. Данный цикл перебирает этот набор и находит маркер (в данном случае, он единственный, выпущенный ACS). Затем выполняется поиск конкретного типа (прописанный в коде URI, оканчивающийся на /action, идентифицирует утверждение Action) и проверяется наличие значения, указанного вызывающей стороной («Calculator.Add», например), и

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

public static void DemandActionClaim(string claimValue){ foreach (ClaimSet claimSet in OperationContext.Current .ServiceSecurityContext .AuthorizationContext .ClaimSets) { foreach (Claim claim in claimSet) { if (AccessControlHelper.CheckClaim(claim.ClaimType, claim.Resource.ToString(), "http://docs.oasis-open.org/wsfed/authorization/200706/claims/action", claimValue)) { if (AccessControlHelper.IsIssuedByIbn(claimSet)) { return; } } } } throw new FaultException("Access denied.");}

Рис. 22: Код вспомогательного метода DemandActionClaim

На рис. 23 представлен результат выполнения клиентского приложения, для которого настроены все эти четыре правила. Я убедился в том, что правильно ввел имя решения и пароль, т.е. могу получить доступ. Если бы пароль был введен неправильно, было бы выведено исключение, сообщающее о невозможности аутентифицировать меня на ACS.

Рис. 23: Выполнение клиента со всеми четырьмя утверждениями Action

Запустив решение, возвращаемся к правилам и деактивируем Calculator.Divide, просто убирая соответствующий ему флажок (рис. 20). И опять выполняем клиент. На этот раз, он получил только три из четырех утверждений Action, и ему было отказано в доступе к операции Divide (рис. 24).

1 «Ibn», очевидно, старое внутреннее кодовое имя ACS, поэтому не дайте вспомогательному методу IsIssuedByIbn сбить вас с толку.

Рис. 24: Выполнение клиента после деактивации одного из утверждений Action

Далее, попробуем ввести другое имя решения и пароль для ACS. На рис. 25 представлен результат.

Рис. 25: Выполнение клиента с использованием другого имени пользователя

Как видите, я смог указать имя пользователя и пароль другого решения (xyzzy), но вернемся к рис. 20 и вспомним, что заданные правила ожидают именно утверждения UserName со значением «asolution», а не «xyzzy». Поэтому в результате я получил маркер без утверждений Action и не мог выполнять ни одну из операций сервиса Calculator (например, логика авторизации DemandActionClaim дала сбой, в данном случае).

Наконец, я задал «asolution» с неверным паролем, чтобы имитировать злоумышленника, который захочет использовать приложение, не зная пароля. Что в результате? WCF сформировала исключение, указывающее на то, что вызывающая сторона не может быть аутентифицирована. Итак, ACS даже не делал попытки выпустить маркер в данном случае, потому что он не смог установить достоверность предоставленных мною имени пользователя и пароля.

Если поэкспериментировать с этим примером SDK, можно заметить, что в нем используется модель программирования утверждений, встроенная в WCF в настоящий момент (System.IdentityModel). Вместо этого можно установить Geneva Framework и использовать ее модель программирования. Geneva Framework – это более современный подход к программированию работающих с утверждениями приложений. Он характеризуются большей гибкостью и более богатым набором возможностей, также он точнее представляет будущее программирования продуктов для работы с утверждениями, исходя из тенденций развития Microsoft .NET1.

Более детально и с дополнительными примерами кода .NET Access Control Service рассматривается в документе данной серии «Руководство по Microsoft .NET Access Control Service для разработчиков» (см. Дополнительные ресурсы).

1 Команда ACS использовала модель программирования WCF в примере калькулятора лишь из соображений доступности (на момент поставки SDK они не могли распространять Geneva Framework).

Microsoft® Workflow Service

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

Размещение рабочего процесса в облаке.NET Workflow Service является частью Azure™ Services Platform и интегрируется с сервисами .NET Service Bus и .NET Access Control Service для безопасного координирования взаимодействия посредством сообщений. .NET Workflow Service также обеспечивает инструменты управления для создания и управления типами и экземплярами рабочих потоков и API веб-сервисов для ситуаций, когда требуется создать собственные инструменты.

Поскольку управляющая среда построена на платформе Windows® Azure™, она может масштабироваться по требованию и в значительной степени, при этом организации или разработчику не приходится беспокоиться о планировании большего количества оборудования или программного обеспечения. Благодаря использованию среды выполнения WF экземпляры рабочего потока могут выполняться в пуле серверов и перемещаться с одного сервера на другой в каждом эпизоде выполнения. Управляющая среда включает сервис хранения, который использует безопасные тиражированные сервисы Microsoft SQL Service для сохранения состояния выполняющихся рабочих процессов и для обеспечения возможности восстановления.

На период перехода к обработке данных в облаке .NET Workflow Services предоставляет упрощенный подход для управления сложными взаимодействиями .NET Service Bus в создаваемых вами составных решениях «в облаке».

Размещение и хранение в облакеПостроение хоста для рабочих процессов WF означает принятие решений о том, какие возможности будет поддерживать среда и как лучше сделать ее безопасной, масштабируемой и стабильной. Сегодня .NET Workflow Service построен на .NET Framework 3.5 и действиях и компонентах WF, входящих в данную версию инфраструктуры. Однако для обеспечения наилучших условий Microsoft были добавлены несколько специальных действий и сервисов, которые наложили некоторые ограничения на рабочие процессы, выполняющиеся в облаке.

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

стабильности, в инфраструктуре облака имеется специальный провайдер услуг хранения, который реализует сохранение состояния выполняющихся рабочих процессов посредством возможностей хранения Microsoft SQL Services. Кроме всего прочего, для Интернет-сервиса необходима Интернет-технология хранения и извлечения данных. Но поскольку механизм WF един – как в облаке, так и в ваших локальных решениях, – применение специального провайдера услуг хранения прозрачно для разработчиков рабочих процессов. Все делается так же, как в любой другое среде WF.

Проектирование рабочих процессов для облакаПри построении рабочих процессов для облака разработчики используют привычные инструменты Visual Studio, включая тот же дизайнер рабочего процесса для создания XAML-файлов рабочих процессов и файлов правил. Затем эти XML-файлы загружаются на сервер в облаке, где они могут использоваться для создания экземпляров рабочего процесса. .NET Services SDK включает шаблон проекта для создания SequentialCloudWorkflow (Последовательный рабочий процесс в облаке), который является специальной версией стандартного шаблона SequentialWorkflow (Последовательный рабочий процесс). Одним из ограничений текущей инфраструктуры является то, что при определении рабочих процессов, которые будут выполняться в облаке, можно использовать только подмножество действий базовой библиотеки действий, а также комплект специальных действий, предоставляемый как часть .NET Services SDK.

Набор действий требует, чтобы рабочие процессы были полностью декларативными и ограничивающими. Это предотвращает введение пользовательского кода, т.е. позволяет гарантировать стабильность среды. При построении управляющей среды для рабочих процессов, написанных любым количеством разработчиков, разбросанных по всему миру, такой уровень контроля является обязательным. Поскольку сегодня для выполнения WF необходимо полное доверие, мы не можем обеспечить ограниченный набор функциональности, просто выделив пользовательский код в безопасную изолированную программную среду на серверах. Следует отметить, что со временем доступный сегодня ограниченный набор действий будет расширен для увеличения возможностей рабочего процесса в облаке. По мере выхода новых версий .NET Framework и .NET Workflow Service также будет поддерживать их. Кроме того, если понадобятся специальные этапы, возможности локальных рабочих процессов могут комбинироваться с рабочими процессами в облаке с помощью .NET Service Bus.

.NET Services SDK содержит новый шаблон проекта для построения рабочих процессов в облаке, набором новых действий в облаке и клиентским API для удаленного развертывания и управления рабочими процессами, размещаемыми в облаке.

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

некоторые основные действия потока управления WF, включая IfElse (Если…то), While (Пока), Sequence (Последовательность), Suspend (Приостановить), Terminate (Завершить) и FaultHandler (Обработчик сбоев). Кроме базовых действий потока управления, в рабочих процесса в облаке могут также использоваться CancellationHandlerActivity и FaultHandlersActivity для моделирования обработки исключений и логики отмены. Обратите внимание, что эти действия обычно не добавляются в модель напрямую; для этого используется дизайнер составных действий, который вводит их автоматически, когда представление переходит к этому действию.

Ни одно другое действие WF или пользовательские действия не могут использоваться. Разрешены к применению только новые специальные действия в облаке, включенные в .NET Services SDK. На рис. 26 описаны новые специальные действия в облаке, которые поставляются с .NET Services SDK.

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

Действие Функция

CloudHttpReceive Принимает HTTP-запросы, отправленные на заданный URL, для экземпляра рабочего процесса

CloudHttpSend Вызывает HTTP-операции GET или POST для заданного URL и принимает ответ

CloudServiceBusSend Отправляет сообщение в заданную конечную точку шины сервисов

CloudServiceBusReceive Принимает сообщения с конечной точки ServiceBusCloudXPathRead Выполняет чтение заданных данных из входящего XML

CloudXPathUpdate Задает указанные данные во входящем XML-документе

CloudDelay Ожидает заданный промежуток времени

Рис. 26: Специальные действия в облаке

.Простой пример сервиса NET Workflow Service

Давайте последовательно рассмотрим простой пример, иллюстрирующий этапы создания и размещения рабочего процесса в облаке с помощью .NET Workflow Service. Спроектируем рабочий процесс для связи с выполняющимся локально WCF-сервисом через .NET Service Bus.

Первый шаг – создание нового проекта консольного приложения в Visual Studio 2008; это будет хост для локального сервиса. Для описания простого контракта и реализации сервиса добавим в этот проект интерфейс и класс, как показано на рис. 27. Введем ссылки на сборки

System.ServiceModel.dll и Microsoft.ServiceBus.dll, чтобы получить поддержку как для WCF, так и для .NET Service Bus.

[ServiceContract(Namespace="")]public interface IHelloService{

[OperationContract(IsOneWay=true)] void SayHello(string input);}public class HelloService : IHelloService{

public void SayHello(string input){

Console.WriteLine(input);}

}

Рис. 27: Простой локальный сервис

Когда сервис определен, необходимо написать некоторый код в файле program.cs, чтобы разместить сервис, соответственно конечной точке .NET Service Bus. В данном примере сервис будет вызываться рабочим процессом, поэтому используйте NetEventRelayBinding и настройте TransportClientEndpointBehavior для аутентификации на .NET Service Bus по учетным данным UserNamePassword, как показано на рис. 28.1

ServiceHost host = new ServiceHost(typeof(HelloService));

ServiceEndpoint ep = host.AddServiceEndpoint("HelloCloudService.IHelloService",

new NetEventRelayBinding()," sb://{решение}.servicebus.windows.net/Hello");

TransportClientEndpointBehavior tb = new TransportClientEndpointBehavior();tb.CredentialType = TransportClientCredentialType.UserNamePassword;tb.Credentials.UserName.UserName = "{решение}";tb.Credentials.UserName.Password = "{пароль}";

ep.Behaviors.Add(tb);

host.Open();Console.WriteLine("Host is listening");Console.ReadLine();host.Close();

Рис. 28: Размещение локального сервиса

1 При воспроизведении этого примера не забывайте заменять имя решения и пароль собственными именем решения и паролем.

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

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

В данном примере добавим в рабочий процесс действие CloudXPathUpdate (Обновление XPath облака). Для этого методом «drag-and-drop» перенесем значок этого действия с вкладки Workflow Activities (Действия рабочего процесса) панели инструментов Visual Studio. Зададим свойству InXml (Входящий Xml) значение «<SayHello><input></input></SayHello>» (вводите эти значения без кавычек). Обратите внимание, что элемент «input» в настоящее время пуст. Чтобы заполнить его, задайте свойству XPathExpression (Выражение XPath) значение «/SayHello/input», обозначив тем самым целевой узел. Наконец, задайте свойству InNewValue (Новое входящее значение) значение «Hello from cloud workflow» (Привет из рабочего процесса в облаке). Конфигурация действия должна быть подобна представленной на рис. 29.

Рис. 29: Конфигурация действия CloudXPathUpdate

Далее добавляем действие CloudServiceBusSend (Отправка на шину сервисов облака) в конец рабочего процесса. Это действие будет отправлять сообщение, созданное предыдущим действием. Сначала, используя привязку действия, зададим свойство Body (Тело). Таким образом, значение для этого свойства будет считываться из свойства Out (Исходящий Xml) ранее

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

настроенного действия CloudXPathUpdate. Конфигурируем действие, задавая свойству Action значение «urn:IHelloService/SayHello» и свойству ConnectionMode (Режим подключения) значение «MultiCast». Наконец, в качестве значения свойства URL определяем адрес .NET Service Bus, который будет слушать ваш сервис: «sb://{решение}.servicebus.windows.net/Hello».

Теперь для этого действия определены все данные, необходимые для правильного построения сообщения и отправки его в конечную точку на .NET Service Bus. После того, как все сделано, рабочий процесс должен выглядеть, аналогично представленному на рис. 30.

Рис. 30: Готовый рабочий процесс

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

Для тестирования решения убедитесь, что консольное приложение, в котором размещается сервис, является основным проектом, и нажмите CTRL+F5 или выберите Debug | Start Without Debugging (Отладка | Запуск без отладки). Как только сервис зарегистрировал свою конечную точку, правой кнопкой мыши щелкните поверхность разработки Visual Studio для рабочего процесса в облаке и выберите пункт меню «Deploy Workflow» (Развернуть рабочий процесс). При этом появится диалоговое окно публикации, которое предложит ввести данные и учетные данные решения, как показано на рис. 31.

Рис. 31: Диалоговое окно Visual Studio для развертывания рабочего процесса в облаке

Введите имя решения и пароль и нажмите кнопку Deploy & Run (Развернуть и выполнить). После развертывания и запуска приложения, в консольном приложении, в котором размещается ваш подключенный к .NET Service Bus сервис, появится ваше сообщение. Поздравляю с успешным выполнением первого рабочего процесса в облаке!

Кроме интеграции с Visual Studio, .NET Workflow Service обеспечивает интерфейс веб-сервиса для задач управления, включая развертывание типов рабочих процессов и управление экземплярами. SDK поставляется с клиентской библиотекой для интегрирования с интерфейсом управления через традиционный .NET-код. Кроме того, портал .NET Services Portal может использоваться из любого веб-браузера для описания и редактирования типов рабочих процессов, а также управления экземплярами рабочих процессов. Портал, инструментарий Visual Studio и клиентский API вместе обеспечивают надлежащую среду для разработчика, которая в дальнейшем будет расширяться и улучшаться.

Более детально и с дополнительными примерами кода .NET Workflow Service рассматривается в документе данной серии «Руководство по Microsoft .NET Workflow Service для разработчиков» (см. Дополнительные ресурсы).

Обзор

.NET Services объединяет в себе основные стандартные блоки сервисов, необходимые для построения приложений в облаке или работающих с облаком приложений на платформе Azure™ Services Platform. .NET Service Bus позволяет устанавливать связь между существующими локальными приложениями и ресурсами, создаваемыми для работы в облаке. Эти ресурсы в облаке смогут обмениваться данными с локальными сервисами благодаря возможностям обхода сети, предоставляемым ретранслятором .NET Service Bus. Предложенная .NET Service Bus среда подключения предлагает разнообразные схемы обмена сообщениями, включая однонаправленный обмен сообщениями, обмен сообщениями в режиме запрос/ответ,

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

Безопасность доступа к ретранслятору .NET Service Bus обеспечивается средствами .NET Access Control Service. Сервис .NET Access Control Service позволяет реализовывать современную модель безопасности с использованием учетных данных на базе утверждений, не требуя при этом от разработчика построения собственной сложной инфраструктуры безопасности. .NET Service Bus доверяет утверждениям, выпущенным .NET Access Control Service, обрабатывает их и устанавливает, должно ли быть разрешено отправителям или получателям отправлять или слушать определенный адрес .NET Service Bus. При запросе маркера доступа для .NET Service Bus отправители и получатели должны предоставить сервису .NET Access Control Service учетные данные. Это могут быть учетные данные решения, WLID или удостоверения Active Directory (предоставляемые учетные данные настраиваются через портал). После аутентификации .NET Access Control Service выпускает маркер доступа для ретранслятора .NET Service Bus. Это лишь один из примеров возможного применения .NET Access Control Service.

.NET Access Control Service также можно использовать в сочетании с собственными сервисами, при этом модель работы практически аналогична только что описанной. Сначала устанавливается отношение доверия между вашим сервисом и .NET Access Control Service (путем предоставления сертификата). Затем вы настраиваете .NET Access Control Service и задаете типы учетных данных, которым он должен доверять, и некоторые декларативные правила для формирования утверждений, необходимых вашему приложению. Поскольку выпускаемые утверждения будут шифроваться с использованием вашего сертификата, только ваш сервис сможет обрабатывать получаемый в результате маркер доступа. После этого вы можете написать в своем сервисе код для обработки входящих утверждений, предоставляемых .NET Access Control Service (точно так же, как это делает ретранслятор .NET Service Bus). В итоге, вы получаете очень гибкую модель безопасности с использованием удостоверений, основанных на утверждениях. Это позволяет централизовать логику аутентификации и преобразования утверждений при объединении удостоверений от разных источников (WLID, Active Directory, деловых партнеров и пр.).

Наконец, .NET Workflow Service позволяет координировать обмен сообщениями в Интернете в безопасном режиме посредством .NET Service Bus и .NET Access Control Service. Ориентированные на сообщения рабочие процессы проектируются в дизайнере рабочих процессов Visual Studio. SDK поставляется с новым набором действий в облаке, которые могут использоваться для построения описаний рабочих процессов в облаке. После создания XAML-файл описания рабочего процесса (с помощью надстройки Visual Studio) загружается в Azure™ Services Platform для размещения и выполнения. При выполнении экземпляры рабочего процесса могут связываться напрямую с другими сервисами, располагающимися в Интернете, и с сервисами частных сетей через среду .NET Service Bus.

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

Workflow Service интегрирован с .NET Service Bus и .NET Access Control Service и упрощает их интеграцию в бизнес-процессы.

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

Заключение

Платформа Azure™ Services Platform представляет комплексную стратегию, разработанную Microsoft для облегчения разработчикам задач по реализации возможностей обработки данных в облаке. Microsoft® .NET Services – ключевая составляющая этой платформы, созданная специально, чтобы помочь .NET-разработчикам сделать первый шаг. .NET Services предлагает ориентированные на работу в облаке стандартные блоки и инфраструктуру для обеспечения возможности подключения приложений, управления доступом, размещения и управления рабочим процессом. Эти стандартные блоки станут основными средствами организации работы «с облаком» для .NET-разработчиков на годы вперед. Больше информации о .NET Service Bus, .NET Access Control Service и .NET Workflow Service можно найти в документах данной серии, посвященных каждой из этих тем в отдельности.

Дополнительные ресурсы

Ниже представлены ссылки на некоторые ресурсы, которые помогут продолжить ваше образование в области Microsoft® .NET Services в целом и по каждому из основных входящих в этот пакет предлагаемому сервису, которые были описаны в этом документе, в отдельности.

Пакетыдокументов по Microsoft® .NET Services

Введение в Microsoft .NET Services для разработчиков (данный документ)o http :// go . microsoft . com /? linkid =9638347

Руководство по Microsoft® .NET Service Bus для разработчиковo http :// go . microsoft . com /? linkid =9638348

Руководство по Microsoft® .NET Access Control Service для разработчиковo http://go.microsoft.com/?linkid=9638349

Руководство по Microsoft .NET Workflow Service для разработчиковo http :// go . microsoft . com /? linkid =9638350

Ресурсы Microsoft® .NET Services

Azure Services Platformo http://www.microsoft.com/azure/services.mspx

Microsoft® .NET Serviceso http://www.microsoft.com/azure/netservices.mspx

Java SDK для Microsoft .NET Serviceso http://www.jdotnetservices.com/

Ruby SDK для .NET Serviceso http://www.dotnetservicesruby.com/

Об авторе

Аарон Сконнард (Aaron Skonnard) является соучредителем Pluralsight, главным поставщиком учебных курсов Microsoft .NET, как обычных, так и онлайн. Аарон является автором многочисленных книг, статей и официальных документов, а также курсов Pluralsight по Azure Services, REST, WCF и BizTalk. Уже много лет он занимается разработкой курсов, делает доклады на конференциях и обучает разработчиков по всему миру. Его можно найти по адресу http :// pluralsight . com / aaron или http :// twitter . com / skonnard .

Благодарности

Спасибо Кейт Браун (Keith Brown) и Мэтту Милнеру (Matt Milner), моим соавторам по созданию данной серии документов по .NET Services. Разделы данного документа, посвященные управлению доступом и рабочему процессу, – это их заслуга, главным образом.

Выражаю благодарность Джону Шевчуку (John Shewchuk) и Деннису Пилариносу (Dennis Pilarinos) за их прозорливость, что привело к созданию технологий Microsoft® .NET Services и помогло придать новую форму разработке на платформе .NET в облаке. Кроме того, спасибо Анджану Дасу (Anjan Das), Девиду Вортендюку (David Wortendyke) и Скоту Геллоку (Scot Gellock) за их интересные отзывы в ходе написания данного документа.