Вопросы выбора между ASP.NET Web Services и .NET Remoting

По материалам MSDN. Анализируются различные аспекты технологий .NET Remoting и Web Services при выборе протокола взаимодействия с удаленными объектами

Вопросы выбора между ASP.NET Web Services и .NET Remoting

Инфраструктура ASP.NET Web services предлагает несложный API для Web services, основанный на связывании SOAP сообщений с вызовами методов. Клиенты ASP.NET Web services не должны знать ничего о платформе, объектной модели или языке программирования, использованных при построении Web service. Соответственно, сама служба не должна ничего знать о клиенте, отправляющем ей сообщение. Единственно, о чем необходимо договориться - это о формате SOAP сообщения, что выполняется посредством WSDL и XML схемы (XSD).

.NET Remoting предоставляет инфраструктуру для исполнения распределенных объектов. Эта технология открывает все возможности, предоставляемые языками программирования .NET и платформой .Net framework. В результате .NET Remoting предлагает гораздо более развитую функциональность по сравнению с Web Services, включая поддержку передачи объектов по значению или по ссылке, обратные вызовы (callback) и различные способы активизации множественных объектов и управления временем жизни объектов. Для того чтобы использовать .NET Remoting клиент должен знать все эти особенности и, соответственно должен быть построен средствами .NET. Хотя .NET Remoting также поддерживает передачу SOAP сообщений, это не снимает требований к клиентскому приложению.

Сериализация и метаданные

Одним из основных отличий между ASP.NET Web services и .NET Remoting является способ сериализации данных в сообщения и формат, используемый для передачи метаданных.

ASP.NET Web services используют System.Xml.Serialization.XmlSerializer для маршалинга данных в и из SOAP сообщений. Для передачи метаданных используется WSDL и XSD, описывающие содержимое сообщения. Использование WSDL и XSD в "чистом виде" делает метаданные, используемые ASP.NET Web services, портируемыми между различными платформами. Получаемое сообщение может быть использовано на различных платформах, с использованием различных моделей программирования. Однако, это накладывает ограничения на типы данных, открываемых средствами Web service—XmlSerializer способен выполнить маршалинг только для того, что может быть описано в рамках XSD. В частности, XmlSerializer неспособен выполнить маршалинг in-memory представление объекта (object graphs) и предоставляет ограниченную поддержку контейнерных типов.

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

.NET Remoting, IFormatter и Common Language Runtime

Для маршалинга данных в и из сообщения .NET Remoting применяет интерфейс Iformatter, используемый процессором System.Runtime.Serialization. Существует два стандартных форматтера (formatter), System.Runtime.Serialization.Formatters.Binary.BinaryFormatter и System.Runtime.Serialization.Formatters.Soap.SoapFormatter. Как предполагают имена BinaryFormatter и SoapFormatter, обеспечивают маршалинг в бинарный и SOAP форматы соответственно. Для метаданных .NET Remoting использует сборки (assembly), которые содержат всю необходимую информацию об используемых типах данных, эта информация отображается средствами Reflection. Использование метаданных сборки позволяет в полной мере реализовать поддержку системных типов. Однако, такая тесная связка с .Net framework ограничивает применимость систем, построенных с использованием .NET Remoting, полноценными .Net framework клиентами и серверами. В части каналов взаимодействия .NET Remoting поддерживает TCP и HTTP. Сообщения можно посылать по любому из каналов, независимо от формата сообщения.

Remoting и Web Services

Использование SOAP форматтера и HTTP канала неизбежно вызывает вопрос: можно ли использовать .NET Remoting для построения Web services? Ответ, да и нет. Стандартная технология Web service полагается не только на SOAP сообщения, но также и на описание сообщений средствами WSDL и XSD. Remoting способен генерировать определения сообщения в формате WSDL. Однако, тут возникает ряд проблем.

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

Во-вторых, сгенерированный WSDL включает специфические для .NET Remoting расширения.

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

Так что, строго говоря, использовать .NET Remoting для построения Web services возможно. Но область применимости может быть несколько ограничена в силу того, что не все типы данных могут быть использованы (например, такой тип как .NET Framework DataSet). Кроме того, следует избегать использования объектов и событий, активируемых клиентом. Если коротко, то придется оставаться в рамках того, что поддерживается ASP.NET Web services.

Однако, еще лучше использовать именно ASP.NET Web Services ибо они именно для этого и создавались.

Архитектура распределенных приложений: ASP.NET Web Services и .NET Remoting

ASP.NET Web services предпочитают систему типов, используемую в XML схемах, в результате обеспечивая более широкую совместимость и упрощенную модель программирования. .NET Remoting предпочитает систему типов, поддерживаемую библиотеками исполнения (runtime) Net framework и предоставляет гораздо более богатую модель программирования за счет более ограниченной совместимости. Это основное отличие двух технологий. Тем не менее, есть и еще целый рад аспектов, учитываемых при построении распределенных систем: транспортные протоколы, хост процессы, безопасность, производительность, способность сохранения состояния, поддержка транзакций и пр..

Транспортные протоколы и хост процессы

Хотя спецификация SOAP не указывает на обязательное использование HTTP в качестве транспортного протокола, клиент может обратиться к Web services, построенных средствами ASP.NET Web services только по HTTP, так как это единственный поддерживаемый протокол. Сервисы инициализируются через IIS и исполняются в рабочем процессе ASP.NET (aspnet_wp.exe).

.NET Remoting предоставляют более широкий выбор и позволяют размещать (host) удаленные объекты внутри любого типа приложения: Windows Form, сервис Windows, построенный средствами .Net, консольное приложение или рабочий процесс ASP.NET. Как говорилось ранее .NET Remoting предлагает использование двух транспортных каналов - TCP и HTTP. Оба канала обеспечивают коммуникацию между произвольно выбранными посылающим и принимающим процессами посредством сокетов (socket).

Есть также возможность интегрировать HTTP канал с IIS рабочим процессом ASP.NET. Это немаловажно по следующим причинам: во-первых, это единственный способ автоматически стартовать принимающее приложение по прибытии клиентского запроса. .NET Remoting не включает менеджер управления сервисами (Service Control Manager - SCM), как это сделано в DCOM. Если вы открываете удаленные объекты из произвольного процесса, то следует убедиться, что этот процесс запущен. Кроме того, вам следует гарантировать, что объект thread-safe, т.е. что thread A не может активировать объект, после того как thread B начала завершение процесса. Если вы открываете удаленные объекты через ASP.NET, можно использовать тот факт, что рабочий процесс Aspnet_wp.exe способен выполнять автозапуск и thread-safe. Во-вторых, интеграция с IIS - единственный способ обеспечить разграничение доступа между межпроцессными вызовами .NET Remoting call.

Разграничение доступа

Так как ASP.NET Web services используют HTTP, они интегрируются в стандартную инфраструктуру разграничения доступа Интернет. ASP.NET использует функциональность IIS для обеспечения стандартных схем аутентификации, включая Basic, Digest, цифровые сертификаты и даже Microsoft® .NET Passport. (можно также использовать Windows Integrated authentication, но только в рамках доверительных отношений между доменами) Одно из преимуществ использования аутентификации по HTTP заключается в том, что не требуется никаких модификаций кода; IIS выполняет аутентификацию до того как выполняется вызов ASP.NET Web services. ASP.NET кроме того, предоставляет поддержку аутентификации средствами .NET Passport и другие схему аутентификации. Для защиты данных при передаче по сети можно использовать SSL.

Как упоминалось выше .NET Remoting не обеспечивает разграничение доступа при межпроцессных вызовах. Если конечная точка .NET Remoting размещена в процессе IIS, то ASP.NET может использовать все те средства разграничения доступа, которые доступны ASP.NET Web, включая SSL. При использовании TCP или HTTP канала, и компонент размещен в ином, чем aspnet_wp.exe процессе, вам необходимо самостоятельно реализовать механизмы аутентификации, авторизации и поддержки секретности.

При необходимости исполнять код в рамках частично доверяемой среды, следует иметь ввиду, что клиентские прокси компоненты ASP.NET Web Services работают в таком окружении, а .NET Remoting нет. Для обеспечения работоспособности .NET Remoting в таком окружении необходимо менять политики реализации безопасности. Для ASP.NET Web Services эти изменения не требуются.

Управление состоянием

Модель ASP.NET Web Services по умолчанию предполагает использование stateless модели, сама по себе она не умеет коррелировать множественные вызовы от одного клиента. Более того, при каждом вызове создается новый объект, обслуживающий запрос. По окончании вызова объект уничтожается. Для сохранения состояния следует использовать те же самые под ходы, которые реализованы для обычных ASP.NET приложений, т.е. использование сессии и Application property bag, либо организовать собственное решение.

.NET Remoting поддерживает несколько вариантов управления состоянием, которые могут или нет коррелировать множественные запросы от одного пользователя, это зависит от выбранной схемы ограничения области видимости объекта (object lifetime scheme). Объекты типа SingleCall не имеют состояния (подобно объектам, используемым для активизации ASP.NET Web services), объекты типа Singleton имеют разделяемого состояние для всех клиентов, а активизируемые клиентом объекты (client-activated objects) поддерживают состояние для каждого индивидуального клиента (со всеми вытекающими ограничениями по масштабируемости и надежности).

Производительность

С точки зрения "чистой" производительности .NET Remoting быстрее при использовании TCP канала и бинарного форматтера. Почти во всех тестах на сравнительную производительность, при использовании SOAP форматтера, ASP.NET Web services работали быстрее чем .NET Remoting при использовании HTTP или TCP канала. При использовании бинарного форматтера ASP.NET и .NET Remoting показывали сходную производительность по HTTP каналу. (см. Performance Comparison: .NET Remoting vs. ASP.NET Web Services.)

Enterprise Services

Как ASP.NET Web Service так и объект, открытый по .NET Remoting может использовать локальные транзакции для координации действий с определенной БД. При необходимости координации транзакции с несколькими БД объект может использовать .NET Enterprise Services (т.е. COM+) и декларативные транзакции (управляемые DTC через COM+). Важно понимать, что ни ASP.NET Web services ни .NET Remoting не поддерживают распространение (propagating) декларативной транзакции, так что невозможным является наследование декларативной транзакции при межпроцессном вызове.

Не факто, что это так уж плохо. В целом, декларативная транзакция обходится дороже, чем локальная, а при распространении декларативной транзакции между процессами, цена только возрастает. Если это принципиально необходимо, то можно построить класс на базе System.EnterpriseServices.ServicedComponent и использовать его в серверном приложении (см COM+ Integration: How .NET Enterprise Services Can Help You Build Distributed Applications). Межпроцессные вызовы к такого типа объектам будут управляться посредством DCOM, что обеспечивает необходимые средства распространения транзакции. Можно также использовать низкоуровневый API, чтобы сделать все руками, но это не так просто.

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

Выбор архитектуры

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

Начните с использования ASP.NET Web services. Они проще в реализации использовании, предлагают наибольший уровень совместимости, а клиентский прокси может исполняться в контролируемой среде.

При необходимости создать более традиционное приложение с распределенной моделью вызова объектов и полной функциональностью, предлагаемой CLR, без необходимости высокой степени совместимости, при том, что вы контролируете конфигурацию клиентских компьютеров и серверов, рассмотрите .NET Remoting. При использовании .NET Remoting предпочтительно использование HTTP канала, интегрированного с IIS и ASP.NET, в противном случае придется разрабатывать собственную инфраструктуру разграничения доступа и управления временем жизни компонентов. Учитывая что .NET Remoting требует .NET клиента, имеет смысл использовать бинарный форматтер вместо SOAP форматтера; производительность будет существенно выше.

Ниже приведены три стандартные архитектуры, основанные на приведенных выше рассуждениях.

Рис 1. Простая трехуровневая архитектура

Рис. 1 показывает простую трехуровневую архитектуру с использованием фермы Web серверов и различных клиентов. Весь серверный код исполняется в рамках рабочего процесса ASP.NET (aspnet_wp.exe). Три различных типа клиентов обращаются к ферме по HTTP. Клиенты, использующие браузер, вызывают ASP.NET страницы, толстые клиенты (Windows Forms, Microsoft® Visual Basic® 6) и иные Web services используют ASP.NET Web services; а толстые .NET клиенты (Windows Forms) и Web services используют ASP.NET Web services или .NET Remoting использованием HTTP канала и бинарного форматтера.

Рис 2. Многоуровневая архитектура с использованием ASP.NET

Некоторые очень крупные приложения могут использовать вторую линию серверов для разгрузки внешней линии Web серверов. Это показано на Рис. 2. Обратите внимание, что, в этом случае, вторая линия также использует ASP.NET.

Рис. 3. Многоуровневое приложение с использованием Enterprise Services (COM+)

На Рис. 3 показана альтернативная версия этой архитектуры с использованием COM+ на серверах второй линии(ServicedComponents развернутые в среде COM+).

Заключение

Хотя и .NET Remoting и ASP.NET Web services обеспечивают кросс процессное взаимодействие, каждая из технологий спроектирована для предоставления услуг определенной целевой аудитории. ASP.NET Web services предлагает простую модель программирования и высокий уровень совместимости. .NET Remoting предлагает более сложную модель программирования и гораздо более узкую область совместимости.