Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ООП / ООП / ры_приложений_полная_книга.pdf
Скачиваний:
528
Добавлен:
18.02.2017
Размер:
7.08 Mб
Скачать

Для сервисов, доступ к которым осуществляется через Интернет, используйте протокол HTTP.

Для сервисов, доступ к которым осуществляется в рамках частной сети, используйте протокол TCP.

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

Технология ASMX

ASMX обеспечивает более простое решение для создания Веб-сервисов на базе ASP.NET и их предоставления через Веб-сервер IIS. ASMX имеет следующие характеристики:

Обеспечивает возможность доступа через Интернет с использованием только протокола HTTP. По умолчанию использует порт 80, но изменить это не составляет никакого труда.

Не поддерживает транзакций координатора распределенных транзакций

(Distributed Transaction Coordinator, DTC). Для программирования длительных транзакций необходимо использовать собственные реализации.

Поддерживает аутентификацию IIS, роли, хранящиеся как группы Windows для авторизации, олицетворение IIS и ASP.NET и безопасность на транспортном уровне с использованием протокола SSL.

Поддерживает технологию конечных точек, реализованную в IIS.

Обеспечивает возможность межплатформенного взаимодействия.

Дополнительные источники

Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.

«Data Transfer and Serialization» (Передача и сериализация данных) по адресу http://msdn.microsoft.com/en-us/library/ms730035.aspx.

«Endpoints: Addresses, Bindings, and Contracts» (Конечные точки: адреса, привязки и контракты) по адресу http://msdn.microsoft.com/en-us/library/ms733107.aspx.

«Messaging Patterns in Service-Oriented Architecture» по адресу http://msdn.microsoft.com/en-us/library/aa480027.aspx.

«Principles of Service Design: Service Versioning» (Принципы проектирования сервисов: контроль версий) по адресу http://msdn.microsoft.com/enus/library/ms954726.aspx.

«Web Service Messaging with Web Services Enhancements 2.0» (Web Service Messaging

с расширениями Web Services Enhancements 2.0) по адресу http://msdn.microsoft.com/en-us/library/ms996948.aspx.

«Web Services Protocols Interoperability Guide» (Руководство по возможности взаимодействия протоколов Веб-сервисов) по адресу http://msdn.microsoft.com/enus/library/ms734776.aspx.

«Windows Communication Foundation Security» (Безопасность Windows Communication Foundation) по адресу http://msdn.microsoft.com/enus/library/ms732362.aspx.

«XML Web Services Using ASP.NET» (Веб-сервисы XML с использованием ASP.NET) по адресу http://msdn.microsoft.com/en-us/library/ba0z6a33.aspx.

19

Физические уровни и развертывание

Обзор

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

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

Изучите целевую физическую инфраструктуру развертывания.

Исходя из инфраструктуры развертывания, выявите ограничения архитектуры и дизайна.

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

Распределенное и нераспределенное развертывание

При выработке стратегии развертывания, прежде всего, необходимо определиться, какая модель развертывания будет использоваться: распределенное или нераспределенное

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

Нераспределенное развертывание

При нераспределенном развертывании вся функциональность и слои приложения, кроме функциональности хранения данных, располагаются на одном сервере, как показано на рис. 1.

Рис. 14

Нераспределенное развертывание

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

Распределенное развертывание

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

Рис. 15

Соседние файлы в папке ООП