XML-столбцы. Этот шаблон позволяет потребителям расширять модель данных произвольным образом неограниченным числом расширений путем сохранения данных расширения в XML-столбце. При использовании подхода с XML-столбцами учтите следующие факторы:
◦Тогда как данный подход может казаться наиболее естественным выбором для обеспечения расширяемости, он обладает меньшей масштабируемостью (возможность добавлять записи) и производительностью (время ответа на запрос) по сравнению с остальными подходами.
◦Тогда как применение XML-столбцов в базе данных обусловливает относительно простые реализации, ISV и разработчикам потребуются дополнительные навыки для работы с XML в базе данных.
◦Для XML-столбцов можно определить индексы, но это вводит дополнительную сложность и требует больше памяти для хранения.
Управление удостоверениями
Все приложения и сервисы должны работать с удостоверением пользователя. Особенно важно это для размещаемых сценариев и сценариев в облаке, которые потенциально могут обслуживать очень большое количество пользователей, и каждый из этих пользователей может иметь собственную инфраструктуру удостоверений. Обычный подход для поставщиков услуг размещения – делегирование ответственности за управление собственными учетными данными самим пользователям. Идеальным является решение, использующее преимущество локального или интегрированного сервиса каталогов пользователя для поддержки единой регистрации (SSO) для локальных и всех внешних размещенных сервисов. Это сокращает объем работ по созданию индивидуальных или отдельных систем управления удостоверениями. Потребители могут настраивать доступ к приложению, используя привычные инструменты, и благодаря SSO пользователи могут выполнять доступ к приложению или сервису с помощью существующих учетных данных.
Чтобы реализовать такой сценарий, необходимо принять решение, основанное на отраслевых стандартах, действующих на всех платформах и во всех организациях. Как правило, следует придерживаться модели удостоверений на основании утверждений на базе интегрированного сервиса удостоверений, как показано на рис. 1. Это позволит отделить приложения и сервисы от механизма аутентификации.
Рис. 43
Модель удостоверений на основании утверждений на базе интегрированного сервиса удостоверений
Существующая система удостоверений пользователя с каждым запросом к приложению передает криптографически подписанный маркер доступа, содержащий набор утверждений о каждом пользователе. Компании, предоставляющие услуги размещения, которые доверяют системе удостоверений пользователя, могут создавать приложения и сервисы, выполняющие авторизацию только необходимых утверждений. Система удостоверений пользователя должна реализовывать STS, который аутентифицирует пользователей, создает и подписывает маркеры доступа стандартного формата и предоставляет сервис для выпуска этих маркеров, основанный на отраслевых стандартах, таких как WS-Trust и WS-Federation. Microsoft Geneva Framework1 и Geneva Server2 во многом обеспечивают необходимую для реализации этих требований инфраструктуру. При реализации модели удостоверений на основании утверждений следует обратить внимание на следующие вопросы:
1Переименовано в Windows Identity Foundation или WIF (прим. научного редактора).
2Переименовано в Active Directory Federation Services v2 или ADFS v2 (прим. научного редактора).
Если доступно подходящее хранилище удостоверений, используйте его для обеспечения единой регистрации для всех локальных приложений, размещаемых Вебприложений и других размещаемых сервисов.
Для небольших или ориентированных на потребителя приложений, если нет доступного хранилища удостоверений, используйте такой сервис, как .NET Services Access Control, интегрированный в Windows Live1, или решение от стороннего производителя.
Может возникнуть необходимость внесения изменений в утверждения, сформированные локальным STS, для выполнения требований поставщика услуг размещения. Или поставщикам услуг размещения может понадобиться реализовать системы преобразований для разных STS-механизмов пользователей. Уровень преобразований обеспечит .NET Access Control Service, или его можно реализовать самостоятельно с помощью Geneva Framework. Более подробная информация о Geneva Framework представлена по адресу http://msdn.microsoft.com/enus/security/aa570351.aspx.
Пути реализации основанных на стандартах продуктов разных поставщиков могут отличаться очень незначительно. Проблемы с совместимостью и возможностью взаимодействия возникают, только если эти продукты следуют стандартам не строго или обеспечивают немного разную их реализацию.
Если решено создавать собственный STS, обеспечьте его защиту от атак. В этом сервисе содержатся все данные аутентификации, поэтому его уязвимость приведет к уязвимости приложений. Также обеспечьте устойчивую к ошибкам и надежную реализацию STS, которая способна обработать все предполагаемые объемы запросов. Сбой STS приведет к тому, что пользователи не смогут выполнять доступ ко всем приложениям, зависящим от него.
Многотенантная архитектура
Отдельные тенанты совместно используют оборудование и инфраструктуру поставщика услуг размещения, а также базы данных и системы баз данных (каждый тенант – это организация, в которой может быть более одного пользователя). Поставщики сервисов должны обеспечивать для размещаемых сервисов платформу с соответствующей емкостью и производительностью. Также они должны продумать, как будут контролировать систему затрат и обеспечивать настройку через конфигурацию. Существует четыре общих этапа перехода к эффективной многотенантной архитектуре с поддержкой пользовательской конфигурации. Эти этапы описываются в следующих разделах:
Собственная архитектура. Каждый потребитель выполняет отдельную копию ПО, предназначенную только для него, и единственный способ поддерживать множество потребителей – предоставление им разных копий ПО. Более того, поскольку
1 В финальной версии .NET Access Control Services интерграция с Windows Live не поддерживается (прим. научного редактора).
практически ничего не обеспечивает возможности настройки через конфигурацию, каждая копия включает настройки конкретного пользователя в форме собственного кода расширения, собственных процессов и/или собственных расширений данных. Хотя, технически, ПО поставляется как сервис (оно не выполняется локально у потребителя), повышения эффективности от роста масштабов достичь невозможно, поскольку все потребители выполняют разные экземпляры ПО. Такая модель может быть отправной точкой для проверки правильности бизнес-модели, но от нее необходимо отказаться, как только количество потребителей начинает увеличиваться. Она не годится для управления тысячами потребителей.
Настраиваемая архитектура. ПО настраивается для каждого конкретного пользователя через конфигурацию и без применения собственного кода. Все тенанты выполняют один и тот же код. Однако архитектура все равно не является многотенантной, и каждый потребитель выполняет собственную копию кода, несмотря на то что копии идентичны. Разделение может быть либо виртуальным (виртуальные машины на одном сервере), либо физическим (выполнение на разных компьютерах). Эта модель является существенным улучшением по сравнению с описанной выше моделью собственной архитектуры, тем не менее, архитектура по-прежнему не допускает настройки через конфигурацию, и вычислительные мощности не разделяются между экземплярами. Поэтому поставщик не может добиться повышения экономической эффективности от роста масштабов использования.
Многотенантная архитектура. UI может настраиваться для каждого тенанта в отдельности, как и бизнес-правила, и модель данных. Настройку каждый тенант выполняет исключительно через конфигурацию с использованием инструментов для самостоятельной настройки, что снимает ответственность за настройку с поставщика сервиса. Этот уровень является практически идеальным вариантом SaaS; единственный недостаток – никакой возможности горизонтального масштабирования, расширение может быть достигнуто только через вертикальное масштабирование.
Масштабируемая архитектура. Такая архитектура поддерживает многотенантность и конфигурацию, плюс возможность горизонтального масштабирования приложения. Новые экземпляры ПО могут без труда добавляться в пул экземпляров для обеспечения динамической поддержки возрастающей нагрузки. Соответствующее секционирование данных, дизайн компонентов без сохранения состояния и совместный доступ к метаданным являются частью дизайна. На этом уровне появляется подсистема балансировки нагрузки тенантов (Tenant Load Balancer) (реализованная с использованием механизмов циклического обслуживания или на основании правил). Эта подсистема обеспечивает повышение степени использования ресурсов размещающей стороны, таких как ЦП и хранилище. Это означает, что общая нагрузка распределена по всей доступной инфраструктуре. Также периодически выполняется реорганизация данных для усреднения нагрузки по обработке данных на каждый экземпляр. Архитектура является масштабируемой, многотенантной и настраиваемой через конфигурацию.