Будущее распределенного программирования
В последних четырех главах мы изучили несколько разных способов сетевого взаимодействия: Web-службы на основе ASP.NET, .NET Remoting, Очереди Сообщений, Службы Уровня Предприятия (Enterprise Services) с DCOM в качестве коммуникационного протокола. Каждая из этих технологий имеет свои преимущества и недостатки. Если говорить о написании Web-служб с применением ASP.NET, то такие службы могут быть использованы с разных платформ, в то время, как .NET Remoting и DCOM привязаны к платформе Microsoft; если сравнивать производительность всех этих коммуникационных технологий, то DCOM – самая быстрая из них, за ней идет .NET Remoting и ASP.NET. Очень различаются механизмы их расширения. Web-службы ASP.NET могут быть расширены применением заголовков SOAP, в то время, как .NET Remoting использует разъемы (sinks). Расширения DCOM не поддерживаются. Некоторые средства этих технологий перекрываются, но наилучший выбор обычно заключается в применении их сочетаний. Например, для многих приложений Web-службы используются, как передний план для обслуживаемых компонентов. Все эти технологии имеют различные модели программирования, что требует высокой квалификации разработчиков. За какой из них будущее?
В этой главе мы поговорим о будущем коммуникационных технологий, а именно – Windows Communication Foundation (фундамент коммуникаций Windows – WCF). WCF представит средства, которые доступны сегодня Web-службам ASP.NET, .NET Remoting, Очередям Сообщений и Службам Уровня Предприятия. В существующих решениях есть и хорошие и плохие стороны. WCF комбинирует все лучшее, что в них есть, в форме совершенно новой технологии. Однако для использования WCF совсем не обязательно переписывать существующие приложения. WCF будет поддерживать интеграцию существующих на сегодняшний день технологий.
Поскольку на момент написания этой книги WCF еще не реализован, в этой главе мы сосредоточимся на изложении идей, касающихся того, как WCF может заменить существующие технологии коммуникаций, а также составим представление о том, как следует применять сегодняшние технологии так, чтобы легко перейти к новой, когда она будет готова.
В частности, в этой главе мы обсудим следующие темы:
· Проблемы сегодняшнего дня
· Спецификации Web-служб
· Обзор WCF
· Программирование WCF
· Подготовка к WCF
Проблемы сегодняшнего дня
В предыдущих главах мы изучили ряд средств, которые представляет .NET для высокоуровневых сетевых коммуникаций. Одним из них является технология .NET Remoting, использующая объектно-ориентированный подход. В .NET Remoting объекты могут создаваться и использоваться между доменами приложений, что также включает их сетевое взаимодействие. Применение связок объектов имеет тот недостаток, что типы данных используются совместно клиентами и серверами, что не только затрудняет работу с различными платформами, но кроме того также затрудняет возможность сохранения контакта клиентов с серверами при разработке новых удаленных объектов, потому что новые версии сборок объектов должны быть доставлены на клиент.
Как правило, клиентская система нуждается в сборке удаленного объекта. Требование наследования класса удаленного объекта от MarshalByRefObject возможно, не самое лучшее проектное решение, поскольку исключает возможность наследования от другого класса. Средства обеспечения безопасности были добавлены позднее в .NET Remoting, но сейчас в .NET 2.0 они представлены. Что действительно хорошо в этой технологии, - так это ее настраиваемость. Можно заменять каналы, используя другие транспортные протоколы, разрабатывать различные форматеры и расширять поток вызовов, применяя разъемы сообщений.
DCOM – протокол, применяемый Службами Уровня Предприятия для передачи контекстов по сети. DCOM – очень быстрый протокол, но он не предусматривает поддержки настраиваемых расширений. При использовании DCOM технологии Microsoft должны быть доступны как на клиенте, так и на сервере, кроме того, на клиентской системе должны быть инсталлированы прокси-объекты. Службы Уровня Предприятия упрощают применение на серверной стороне таких вещей, как транзакции, пулинг объектов, и т.п. В этой технологии для определения требований к обслуживаемым компонентам применяются атрибуты. Поскольку инсталляция клиентских прокси-объектов часто не так проста, особенно в масштабных решениях, в качестве переднего плана применяются Web-службы.
ASP.NET – технология, используемая сегодня для разработки Web-служб. Они не только дают возможность взаимодействия клиентов и серверов, работающих на разных платформах, но позволяют планировать изменения наперед, - за счет определения хорошего контракта WSDL, не нарушая целостности существующих клиентов и серверов. Web-службы ASP.NET используют протокол HTTP (с WCE 2.0 также доступны каналы TCP), хотя XML-сериализация с протоколом SOAP недостаточно быстра для всех случаев, а некоторые средства расширения трудно использовать. Помимо четкого контракта, который представляет собой единственный разделяемый элемент между клиентом и сервером, Web-службы ASP.NET могут легко разрабатываться с использованием атрибутов. Наследование от определенного базового класса при этом не требуется.
Web-службы
Web-службам и ASP.NET посвящено много публикаций. Вокруг этой технологии в последние годы было поднято много шума, в особенности это касалось возможностей представления сервиса между разными платформами. Но то, что мы видели до сих пор, - лишь первый шаг в направлении тех возможностей, которые может предоставлять эта технология. Чтобы строить мощные интероперабельные службы с учетом требований лицензирования, обеспечением гарантированной доставки сообщений, платформенно-независимой аутентификации, авторизации и конфиденциальности, Web-службам требуются некоторые дополнительные средства.
Рассмотрим более подробно один пример. По мере того, как многие отделы крупнейших компаний задумываются об открытии доступа к приложениям своим деловым партнерам, - с тем, чтобы обеспечить более высокую степень интеграции и ускорение бизнес-процессов, политика компаний может столкнуться с ситуацией, когда для отделов станет невозможно контролировать – кто авторизован для доступа к данным. Конечно, не каждый отдел захочет управлять пользователями и иметь дело с проблемами аутентификации. С другой стороны, в больших компаниях также невозможно полностью централизовать управление приложениями, которые рассчитаны на обслуживание нужд отделов.
Что необходимо в таких случаях – это федеративный сервер (federation server). Федерация позволяет разделить идентичности между сегментами сетей. Федеративный сервер использует политику, определяющую, кому и к каким службам на предприятии разрешено обращаться.
Рис. 32-1 показывает федеративный сценарий, где токен безопасности запросчика используется для получения токена безопасности источника ресурсов (которым может быть компания-партнер) для доступа к ресурсам. Между потребителем и поставщиком ресурсов устанавливаются доверительные отношения. Служба токенов безопасности источника ресурсов доверяет поставщику идентификаторов запрашивающей стороны. Токен защиты потребителя проверяется службой токенов безопасности поставщика ресурсов, чтобы определить, разрешен ли этому потребителю доступ к ресурсу.
Федерация определена в спецификации WS-Federation. Спецификации Web-служб можно найти на http://msdn.microsoft.com/webserivces.
Некоторые требования Web-служб в порядке возрастания перечислены ниже:
· Безопасность
· Надежность
· Транзакции
· Производительность
Эти требования и текущие средства их обеспечения мы обсудим в следующих разделах.
Безопасность
Спецификация WS-Security определяет каркас для построения протоколов безопасности. WS-Federation базируется на многих спецификациях безопасности. Основные средства безопасности Web-служб могут включать следующие требования:
· Аутентификация сообщений
· Целостность сообщений
· Конфиденциальность сообщений
Аутентификация определяет, что абонент, присылающий вызов, должен быть идентифицирован. Для идентифицированного абонента следует выполнить проверку, разрешено ли ему использовать ресурсы (что называется авторизацией). Для аутентификации спецификации WS-Security определяют, как передавать токены безопасности в ответ на SOAP-запрос.
Простой пример передачи имени пользователя показан в следующем сегменте заголовка SOAP. Имя пользователя определено в элементе <wsse:UsernameToken>. Элемент <wsse:Username> определен, как расширяемый, который допускает дополнительные атрибуты:
<S:Header>
...
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>Christian</wsse:Username>
</wsse:UsernameToken>
</wsse:Security>
</S:Header>
Токены безопасности могут быть определены, как бинарные, - элементом <wsse:BinarySecurityToken>, или в формате XML.
Спецификация WS-SecureConversation определяет, как безопасным образом могут передаваться сообщения. Следующий пример показывает применение токена защиты контекста. Здесь установлено соединение между клиентом и сервером, и ключ защиты также согласован. Ключ защиты применяется для шифрования тела сообщения:
<S:Envelope xmlns:S=”http://www.w3.org/2003/05/soap-envelope”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”
xmlns:wsse=
“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”
xmlns:wst=”http://schemas.xmlsoap.org/ws/2004/04/trust”
xmlns:wsc=”http://schemas.xmlsoap.org/ws/2004/04/sc”>
<S:Header>
...
<wsse:Security>
<wsc:SecurityContextToken wsu:Id=”MyID”>
<wsc:Identifier>
uuid:09190A0B-9C3D-4a61-944C-164A9E385D4E
</wsc:Identifier>
</wsc:SecurityContextToken>
<ds:Signature>
...
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI=”#MyID”/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body wsu:Id=”MsgBody”>
<tru:StockSymbol
xmlns:tru=”http://fabrikam123.com/payloads”>
QQQ
</tru:StockSymbol>
</S:Body>
</S:Envelope>
Надежность
Протокол HTTP не надежен: сообщения могут теряться, дублироваться, поступать в другом порядке. Спецификация WS-ReliableMessaging определяет протокол интероперабельности, который может гарантировать доставку сообщений.
WS-ReliableMessaging определяет последовательность и нумерацию сообщений, с тем, чтобы сообщения отправлялись и получались исключительно однократно и в определенном порядке. Чтобы гарантировать доставку, от получателя возвращается подтверждение. Если посылается большое количество сообщений и подтверждений, это вызывает высокий уровень трафика. Также в случае утери сообщений возможно получение ответов NACK (not acknowledged or negative acknowledgements – отсутствие подтверждения или отрицательное подтверждение).
WS-ReliableMessaging использует следующие механизмы для обеспечения надежной передачи сообщений:
· Последовательности: Когда сообщения пересылаются от источника получателю, применяется уникальный идентификатор, определяющий последовательность сообщений. Несколько сообщений могут принадлежать одной последовательности.
· Номера сообщений: В пределах последовательности сообщения пронумерованы. Каждое из них имеет уникальный номер в пределах последовательности. Вместе с каждым сообщением пересылается количество сообщений, чтобы получатель мог узнать, когда все сообщения получены. Если сообщения приходят в неправильном порядке, клиент может их кэшировать, чтобы переупорядочить.
· Подтверждения: Подтверждение отправляется для извещения об успешном приеме сообщения. Для повышения производительности одно подтверждение может быть отправлено в ответ на диапазон сообщений (например, о том, что успешно приняты сообщения 1-5). Также для повышения производительности получатель может отправлять отрицательные подтверждения, чтобы запросить повторной отправки некоторых сообщений.
Рис. 32-2 показывает, как механизм надежных сообщений отвязывается от работы приложения, и как он взаимодействует с источником RM (reliable messaging – надежных сообщений) и средствами получателя. Приложение просто посылает сообщение источнику RM, откуда оно перенаправляется получателю RM.
Application source Приложение-источник
RM source transmit Передатчик RM (надежных сообщений)
Application destination Приложение-получатель
RM destination receive Приемник RM (надежных сообщений)
Acknowledge Подтверждение
Пример SOAP-сообщения, которое содержит RM-последовательность, показан в следующем фрагменте SOAP. Вы можете видеть здесь RM-последовательность с префиксом wsrm. Идентификатор http://wrox.com/ab4711 представляет собой уникальный идентификатор последовательности, созданный источником. Этот идентификатор пересылается вместе с каждым сообщением последовательности, так что получатель RM может отобразить сообщения в правильной последовательности. Номер сообщения отправляется внутри элемента <wsrm:MessageNumber>. С последним сообщением последовательности отправляется элемент <LastMessage />. Получив последнее сообщение, приемник должен вернуть ответ с информацией о том, какие сообщения получены:
<S:Envelope xmlns:S=”http://www.w3.org/2003/05/soap-envelope”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”
xmlns:wsp=”http://schemas.xmlsoap.org/ws/2002/12/policy”
xmlns:wsrm=”http://schemas.xmlsoap.org/ws/2004/03/rm”
xmlns:wsa=”http://schemas.xmlsoap.org/ws/2003/03/addressing”>
<S:Header>
<wsa:MessageID>
http://thinktecture.com/guid/9BEF0F9B-459F-462a-B9EE-0ADBA4BEDB13
</wsa:MessageID>
<wsa:To>http://thinktecture.com/training</wsa:To>
<wsa:From>
<wsa:Address>http://wrox.com/services/books</wsa:Address>
</wsa:From>
<wsrm:Sequence>
<wsu:Identifier>http://wrox.com/ab4711</wsu:Identifier>
<wsrm:MessageNumber>10</wsrm:MessageNumber>
<wsrm:LastMessage/>
</wsrm:Sequence>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
Если приемник не получил все сообщения, ответ может выглядеть, как в следующем фрагменте. Здесь приемник подтверждает получение сообщение со 2-го по 5-е и с 7-го по 10-е, то есть сообщения 1 и 6 были потеряны:
<wsrm:SequenceAcknowledgement>
<wsu:Identifier> http://wrox.com/ab4711</wsu:Identifier>
<wsrm:AcknowledgementRange Upper=”5” Lower=”2”/>
<wsrm:AcknowledgementRange Upper=”10” Lower=”7”/>
</wsrm:SequenceAcknowledgement>
Вместо ответа с подтверждением получения сообщений, может быть отправлено отрицательное подтверждение с указанием потерянных сообщений 1 и 6:
<wsrm:SequenceAcknowledgement>
<wsu:Identifier> http://wrox.com/ab4711</wsu:Identifier>
<wsrm:Nack>1</wsrm:Nack>
<wsrm:Nack>6</wsrm:Nack>
</wsrm:SequenceAcknowledgement>
Постоянство (persistence) не определено в спецификации WS-ReliableMessaging. Реализация функциональности надежных сообщений может добавлять механизм постоянства для гарантий доставки сообщений в случае отказа системы. Это можно сравнить с механизмом Очередей Сообщений, описанным в главе 31.
Транзакции
В главе 30, мы уже видели применение транзакций в Службах Уровня Предприятия. Транзакция предполагает получения результата «все или ничего»; либо все действия выполнены, либо ни одно из них. Механизм транзакций в Web-службах описывают три спецификации: WS-Coordination, WS-AtomicTransactions и WS-BusinessActivity. WS-Coordination – базовая спецификация, которую расширяют остальные.
Спецификация WS-Coordination определяет каркас для координации действий распределенных приложений. Эта спецификация обеспечивает возможность координации множество Web-служб. Например, координацию транзакционной обработки и управления рабочим потоком, охватывающим разные Web-службы.
Спецификация WS-AtomicTransactions – расширение WS-Coordination для поддержки транзакций между Web-службами. Функциональность WS-AtomicTransactions некоторым образом подобна атомарным транзакциям в разработках баз данных.
Рис 32-3 показывает сценарий двухфазной фиксации в Web-службах, использующих WS-AtomicTransactions. Координатор посылает сообщение «Подготовиться» (Prepare) всем участвующим Web-службам, на что каждая из них обязана ответить сообщением «Подготовлена» (Prepared), если с ее точки зрения транзакция выглядит корректной. Координатор затем может послать сообщение «Фиксировать» (Commit), которое должно быть зафиксировано всеми участниками.
В случае, если участник не может успешно подготовиться к транзакции, координатору отправляется сообщение «Прервано» (Aborted). Тогда координатор отправляет сообщение «Откат» (Rollback) остальным участникам, как показано на рис. 32-4.
Спецификация WS-AtomicTransactions не должна использоваться между границами компаний, потому что такая транзакция блокирует ресурсы. WS-AtomicTransactions подходит только для краткосрочно живущих транзакций без пользовательской активности.
Для долгосрочных транзакций, включающих пользовательскую активность и другие бизнес-процессы, больше подходит спецификация WS-BusinessActivity. Согласно ей, никакие ресурсы не блокируются, и бизнес-действия могут занимать длительное время. Вместо фиксации и отката транзакций действия могут быть компенсированы. Если на одном из участников происходит сбой транзакции, то всем остальным участникам отправляется сообщение «Компенсировать» (Compensate), - с тем, чтобы они отменили свои действия.
Рис. 32-5 показывает последовательность бизнес-активность двух участников. Участник A посылает сообщение Completed координатору, когда успешно завершает свое действие. Участник B не может успешно завершить свое действие, поэтому посылает сообщение Fault (Сбой). Поскольку на B произошел отказ, участнику A посылается сообщение Compensate, чтобы он отменил свое действие.
Производительность
Некоторым службам требуется повышенная производительность (в частности, - уменьшенные сетевые пакеты) по сравнению с той, которая достижима для протоколов HTTP и SOAP. Поэтому SOAP 1.2 отныне не зависит от протокола HTTP.
Уменьшение сетевых пакетов может быть достигнуто тем, что SOAP базируется не на структурированных элементах XML, а на т.н. наборах информации XML (XML infoset). Это делает возможным бинарный вариант SOAP, при котором нужно пересылать гораздо меньше данных.
Протокол UDP не предусматривает гарантии доставки; очень легко пакеты могут быть потеряны. Преимущество этого протокола – в возможности отправки сообщений множеству получателей сразу, - вместо того, чтобы отправлять каждому поодиночке. Если посмотреть список компаний, которые определили спецификацию SOAP поверх UDP (SOAP-over-UDP), сразу становится ясно, какие системы ее используют. Авторами спецификации являются Lexmark, Ricoh, BEA и Microsoft. Можно ожидать, что принтеры будут посылать информацию о своем состоянии Web-службам управления печатью (Print Manager Web services) в сети.
Для SOAP поверх UDP определены следующие паттерны сообщений:
· Одноадресный, однонаправленный (Unicast one-way): Одноадресные однонаправленные сообщения посылаются одиночному узлу, который не присылает ответов.
· Многоадресный однонаправленный (Multicast one-way): Многоадресные однонаправленные сообщения отправляются группам узлов. Опять же, никакие ответы не посылаются.
· Одноадресный запрос, одноадресный ответ (Unicast request, unicast response): Сообщение отправляется единственному получателю и его ответ приходит обратно.
· Многоадресный запрос, одноадресный ответ (Unicast request, multicast response): Этот паттерн определяет, что запрос посылается группе узлов, и каждый узел, который принимает запрос, присылает ответное сообщение. Ответ не должен быть многоадресным, поскольку это очень легко могло бы привести к перегрузке сети, если каждый отправитель стал бы слать ответы каждому узлу. Конечно, исходный отправитель при этом принимает множество ответных сообщений от каждого узла в многоадресной группе.
Для многоадресных групп определяется специальный ранговый IP-адрес. Каждый узел в группе, принимающий участие в многоадресной сессии, должен зарегистрировать этот IP-адрес группы.
Подробнее о многоадресных протоколах можно прочитать в книге Pro .NET 1.1 Network Programming by Christian Nagel et al., published by APress, ISBN 1590593456.
Пример многоадресного однонаправленного сообщения показан в следующем фрагменте SOAP. Чтобы обратиться к целевым узлам, со спецификацией SOAP-поверх-UDP используется спецификация WS-Addressing, на что указывает префикс wsa. Хотя схема http используется в спецификации назначения, сообщение передается по UDP:
<S:Envelope xmlns:S=”http://www.w3.org/2003/05/soap-envelope”
xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing” >
<S:Header>
<wsa:To>http://MulticastAddress</wsa:To>
<wsa:Action>http://MulticastAddress/Status</wsa:Action>
<wsa:MessageId>
uuid:3613EEA6-1D77-4db8-8C78-A3D6019CD0BD
</wsa:MessageId>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
Теперь, когда мы познакомились с некоторыми спецификациями, призванными облегчить жизнь с Web-службами, в следующем разделе обратимся к архитектуре WCF, которая предусматривает реализацию многих из этих спецификаций.
Обзор WCF
WCF комбинирует функциональность ASP.NET, Web-служб, .NET Remoting, Очередей Сообщений и Служб Уровня Предприятий. Вот что дает WCF:
· Хостинг компонентов и служб: Точно так же, как настраиваемый хостинг используется с .NET Remoting и WSE, службу WCF можно размещать для одноранговых вычислений в исполняющей системе ASP.NET, системной службе Windows, процессе COM+, или просто в приложении Windows Forms.
· Декларативное поведение: Вместо требований наследования от определенного базового класса (такое требование существует в .NET Remoting и Службах Уровня Предприятия), для определения служб могут быть использованы атрибуты. Это подобно Web-службам, разработанным с ASP.NET.
· Коммуникационные каналы: Хотя в .NET Remoting очень легко заменять коммуникационные каналы, WCF представляет хорошую альтернативу, поскольку обеспечивает такую же гибкость. WCF будет представлять множество каналов для коммуникаций HTTP, TCP и IPC. Может быть, также будут доступны каналы UDP (SOAP поверх UDP мы обсудили ранее).
· Инфраструктура безопасности: Для реализации платформенно-независимых Web-служб должна быть использована стандартизованная среда безопасности. Предлагаемые стандарты реализованы в WSE 2.0, и это будет продолжено в WCF.
· Расширяемость: .NET Remoting имеет богатые возможности для расширений. Можно не только создавать пользовательские каналы, форматеры и прокси; также можно встроить функциональность в поток сообщений на клиенте и сервере. WCF будет представлять подобную расширяемость, но расширения будут реализованы применением заголовков SOAP.
· Поддержка сегодняшних технологий: Вместо полного переписывания распределенных решений под WCF, WCF можно интегрировать с существующей технологией. Канал, представленный WCF, взаимодействует с обслуживаемыми компонентами, используя DCOM. Также могут быть интегрированы Web-службы, разработанные в ASP.NET.
WCF имеет очень гибкую многослойную архитектуру. Распределенные приложения могут разрабатываться с применением либо высокоуровневых, либо низкоуровневых программных интерфейсов (API). Программные интерфейсы высшего уровня, или служебный слой, может использоваться для вызова методов и событий. Служебные слой конвертирует эти высокоуровневые абстракции в сообщения, опирающиеся на каналы и порты низкоуровневого API.
Рис. 32-6 показывает слои приложения WCF. Приложение может использовать такие службы сообщений, как очереди, маршрутизация, события и обнаружения. Примерами служебного поведения, предоставляемого распределенным приложениям являются: автоматические транзакции, параллельное управление, обработка ошибок и создание экземпляров. Блок сообщений разделен на две области: транспортные каналы, являющиеся адаптерами транспортных протоколов (например, HTTP, TCP, UDP и IPC), и каналы, добавляющие функциональность, - такую, как обеспечение безопасности, надежности и обмен событиями. Транспортные каналы могут комбинироваться с другими каналами. Раздел сред хостинга показывает, что WCF может опираться на приложения любого типа. Службы WCF могут быть представлены ASP.NET, системными службами Windows, COM+, или отдельными исполнимыми программами. Это очень похоже на организацию приложений .NET Remoting.
Рис. 32-7 показывает взаимодействие различных частей приложения WCF. Сообщение отправляется на именованный порт. Транспортный канал, ассоциированный с транспортным протоколом, пересылает его в канал, откуда сообщение доставляется нужной службе.
Отправка сообщений может осуществляться одним из трех способов:
· Сообщения датаграммами: Датаграммные сообщения посылаются в стиле «послал и забыл». Сообщение отправляется, и никакой ответ от получателя не ожидается. Отправителю нет нужды ожидать ответа. Конечно, для выполнения таких операций методы могут иметь только входные параметры.
· Сообщения «запрос-ответ»: Это наиболее часто используемый сценарий. Отправитель посылает сообщение-запрос получателю, а получатель возвращает ответное сообщение.
· Дуплексные сообщения: При дуплексном обмене сообщениями обе стороны в сети действуют и как отправитель, и как получатель.
Программирование WCF
В процессе программирования клиентов и служб WCF, вы обнаружите множество концепций, знакомых по другим технологиям. Нет ничего совершенно нового, но различные программные модели комбинируются так, что нужно изучить лишь одну модель вместо множества, как это имеет место при использовании разных коммуникационных технологий.
Далее рассмотрим:
· Контракты
· Реализацию служб
· Связывание
· Хостинг
· Клиенты
Контракты
Контракт определяет функциональность, предоставляемую службой, и функциональность, которую может использовать клиент. Контракт может быть полностью независим от реализации службы.
Контракт Web-служб – это документ WSDL. При разработке Web-служб с ASP.NET, контракт не играет столь значительную роль, как это должно быть. В ASP.NET контракты реализованы неявно – через спецификацию атрибутов методов Web-служб. Конечно, для явного проектирования контракта можно использовать инструмент вроде WSCF от Thinktecture (http://www.thinktecture.com).
WCF уделяет значительное внимание проектированию контрактов. Контракты, определенные WCF, можно объединить в три группы: служебные контракты, контракты данных и контракты сообщений. Контракты могут быть специфицированы (это похоже на ASP.NET) посредством атрибутов .NET.
· Служебные контракты: Служебный контракт используется для определения WSDL, описывающего службу. Этот контракт определяется интерфейсами и классами.
· Контракты данных: Контракт данных определяет данные, принимаемые и возвращаемые службой. Классы, используемые для отправки и приема сообщений, имеют ассоциированные с ними контракты данных.
· Контракты сообщений: Если необходим полный контроль сообщений SOAP, контракт сообщения может специфицировать какие данные должны попасть в заголовок SOAP, а какие – в тело SOAP.
WSDL описан в главе 28.
Рассмотрим эти группы контрактов более подробно.
Служебные контракты
Служебный контракт определяет операции, которые служба может выполнять. Для определения служебного контракта используется атрибут [ServiceContract]. Методы, предоставляемые службой, имеют атрибут [OperationContract], как можно видеть на примере службы ICourseRegistration.
[ServiceContract]
public interface ICourseRegistration
{
[OperationContract]
public bool RegisterForCourse(Course course, Attendee attendee);
}
Вместе со служебным контрактом требования, предъявляемые к службе транспортом, определяются атрибутом [BindingRequirements]. Свойство RequireOrderedDelivery определяет, что отправленные сообщения должны появляться в том же порядке. Свойством QueuedDeliveryRequirements можно указать, что сообщения могут отправляться в автономном (disconnected) режиме, - то есть, посредством Очередей Сообщений. Свойством TransactionFlowRequirements можно указать транзакционные требования, как в Службах Уровня Предприятия.
Контракт данных
Посредством контракта данных типы CLR отображаются на схемы XML.
Контракт данных отличается от других механизмов сериализации; при сериализации времени исполнения сериализуются все поля (включая частные), при XML-сериализации – только открытые поля и свойства. Контракт данных требует явной пометки сериализуемых полей, - с помощью атрибута [DataMember]. Этот атрибут может быть использован независимо от того, открытое поле или частное.
[DataContract(Namespace=”http://www.thinktecture.com”]
public class Course
{
[DataMember] public string Number;
[DataMember] public string Title;
[DataMember] public DateTime StartDate;
}
Контракт данных поддерживает контроль версий. С помощью именованного свойства VersionAdded специфицируются дополнительные элементы, которые добавляются более новыми версиями, как показано ниже для LocationCode. Свойство IsOptional указывает, что сообщения от более ранних версий контракта по-прежнему принимаются, то есть LocationCode – опциональное поле.
[DataContract(Namespace=”http://www.thinktecture.com”]
public class Course
{
[DataMember] public string Number;
[DataMember] public string Title;
[DataMember] public DateTime StartDate;
[DataMember(VersionAdded=2 IsOptional=true]
public string LocationCode;
}
Будучи независимыми от платформы и версии, контракты данных – наилучший способ определения пересылаемых данных. Однако также вы можете применять XML-сериализацию и сериализацию времени исполнения. XML-сериализация – это механизм, используемый Web-службами ASP.NET. Сериализация времени исполнения используется .NET Remoting.
Контракт сообщений
Контракт сообщений применяется тогда, когда необходим полный контроль сообщений SOAP. С помощью контракта сообщения можно указать, какая часть сообщения должна попасть в заголовок SOAP, а что должно относиться к телу SOAP. Следующий пример демонстрирует контракт сообщений для класса ProcessPersonRequestMessage. Контракт сообщения специфицируется атрибутом [MessageContract]. Заголовок и тело сообщения SOAP указываются атрибутами [MessageHeader] и [MessageBody]. Указывая свойство Position, можно задать порядок элементов в теле.
[MessageContract]
public class ProcessPersonRequestMessage
{
[MessageHeader]
public int employeeId;
[MessageBody(Position=0)]
public Person person;
}
Класс ProcessPersonRequestMessage с сервисным контрактом, определенным в интерфейсе IProcessPerson:
[ServiceContract]
public interface IProcessPerson
{
[OperationContract]
public PersonResponseMessage ProcessPerson(
ProcessPersonRequestMessage message);
}
Реализация службы
Реализация службы помечается атрибутом [ServiceBehavior], как показано в следующем определении класса CourseRegistrationService:
[ServiceBehavior]
public class CourseRegistrationService : ICourseRegistration
{
public bool RegisterForCourse(Course course, Attendee attendee)
{
// реализация
}
}
Атрибут [ServiceBehavior] применяется для описания поведения, представляемого службами WCF для перехвата кода требуемой функциональности, как показано а следующей таблице.
|
Свойство ServiceBehavior |
Описание |
|
AllowConcurrentTransactions |
Если должны быть разрешены входные транзакции, этому свойству присваивается значение true. |
|
TransactionIsolationLevel |
Для определения уровня изоляции транзакции в службе, свойство TransactionIsolationLevel может быть установлено в одно из значений перечисления IsolationLevel (Serializable, Repeatable, ReadCommitted, ReadUncommitted, Snapshot, Chaos, Unspecified) |
|
AutomaticSessionShutdown |
Если сессия не должна закрываться при закрытия соединения клиентом, нужно установить значение свойства AutomaticSessionShutdown в true. По умолчанию в этом случае сессия закрывается. |
|
InstanceMode |
Этим свойством определяется, будут ли использованы объекты со статусом или без. По умолчанию принято значение InstanceMode.PerCall, что означает создание нового объекта при каждом вызове метода. Это можно сравнить с хорошо известными объектами .NET Remoting – SingleCall. Другие возможные значения: PrivateSession и SharedSession. В обоих этих случаях используются объекты без статуса. Однако с PrivateSession для каждого клиента создается новый объект. SharedSession позволяет разделять одни и те же объекты множеством клиентов. |
|
ConcurrencyMode |
Поскольку объекты без статуса могут быть использованы множеством клиентов (или множеством потоков одного клиента), следует уделить внимание последствиям параллельности при работе с объектами этого типа. Если свойству ConcurrencyMode присвоено значение Multiple, то множество потоков могут иметь доступ к объекту, и потому придется иметь дело с синхронизацией. Если же это свойство будет иметь значение Single, то доступ к объекту будет иметь только один поток в единицу времени. В этом случае синхронизация не нужна; однако, проблемы масштабируемости могут возникнуть с увеличением числа клиентов. Для объектов без статуса значение этого свойства не важно, потому что при каждом вызове метода создается новый экземпляр, а потому состояние не разделено между клиентами, как не разделен и сам объект. |
|
ReturnUnknownExceptionsAsFaults |
В .NET ошибки проявляются в виде исключений. В SOAP определено, что сбой SOAP возвращается клиенту в случае проблем на сервере. По причинам, связанным с безопасностью, считается плохой идеей возвращать клиенту подробности исключений серверной стороны. Потому по умолчанию исключения преобразуются в неизвестные сбои. Чтобы вернуть специфическую информацию о сбое, можно бросить исключение Fault<string>. Для отладки было бы очень полезно вернуть информацию о реальном исключении. В этом случае нужно установить этому свойству значение false. |
|
RunOnUIThread |
Если служба представлена приложением Windows Forms, при вызове методов органов управления пользовательского интерфейса всегда используется один и тот же поток. Это делается автоматически, если установить значение RunOnUIThread в true |
|
ValidateMustUnderstand |
Установка значения true для свойства ValidateMustUnderstand означает, что заголовки SOAP должны быть понятны (так и есть по умолчанию) |
Связывание
Связывание (binding) описывает, как организованы коммуникации службы. При связывании можно указать следующие свойства:
· Транспортный протокол
· Требования безопасности
· Формат кодирования
· Транспортные требования
Связывание состоит из множества элементов, описывающих требования связывания. Можно создать собственное связывание, или использовать одно из предопределенных, перечисленных в следующей таблице:
|
Стандартное связывание |
Описание |
|
BasicProfile |
Связывание BasicProfile обеспечивает наиболее широкую интероперабельность с Web-службами первого поколения. Используются транспортные протоколы HTTP или HTTPS; безопасность обеспечена только средствами протокола |
|
WSProfile |
Связывание WSProfile предназначено для нового поколения Web-служб, платформ, реализующих SOAP-расширения безопасности, надежность и транзакции. Используемый транспорт – HTTP или HTTPS; безопасность обеспечивается реализацией спецификации WS-Security; транзакции поддерживаются в соответствии со спецификациями WS-Coordination, WS-AtomicTransaction и WS-BusinessActivity; надежность обмена сообщениями поддержана реализацией WS-ReliableMessaging. WSProfile также поддерживает кодирование MTOM для отправки вложений (attachments). |
|
WSProfileDualHttp |
Связывание WSProfileDualHttp отличается от WSProfile наличием дуплексного обмена сообщениями. |
|
NetProfileTcp |
Все стандартные связывания с префиксом Net используют бинарное кодирование коммуникаций между приложениями .NET. Это кодирование быстрее, чем текстовое в связках WSxxx. Связывание NetProfileTcpBinding использует протокол TCP/IP. |
|
NetProfileDualTcp |
В отличие от NetProfileTcp, NetProfileDualTcp поддерживает дуплексный обмен сообщениями |
|
NetProfileNamedPipe |
Для коммуникаций между разными процессами на одной и той же системе NetProfileNamedPipe – самый быстрый тип связывания. |
|
NetProfileMsmq |
Связывание NetProfileMsmq обеспечивает в WCF возможность коммуникаций посредством очередей. То есть здесь сообщения отправляются в очередь |
|
MsmqIntegration |
MsmqIntegration – связывание для существующих приложений, использующих очереди сообщений. Связывание MsmqIntegration требует наличия приложений WCF как на клиенте, так и на сервере. |
|
Intermediary |
Связывание Intermediary предназначено для посредников, находящихся между клиентом и службой. Поддерживаются транспортные протоколы HTTP, TCP и именованные каналы. |
Наряду с определением связывания служба должна определять конечную точку (endpoint). Конечная точка зависит от контракта, адреса службы и связывания. В следующем коде создается экземпляра объекта-примера ServiceHost, и адрес http://localhost:9200/CourseRegistrationService вместе с экземпляром WsProfileBinding добавляется в конечную точку службы.
using (ServiceHost<CourseRegistrationService> serviceHost = new
ServiceHost<CourseRegistrationService>())
{
// добавить службе конечную точку WSProfile
Uri address1 = new Uri(“http://localhost:9200/CourseRegistrationService”);
WsProfileBinding binding1 = new WsProfileBinding();
serviceHost.AddEndpoint(typeof(ICourseRegistration), binding, address);
//...
}
Кроме программного определения связывания, его можно определить конфигурационным файлом приложения. Конфигурация для WCF помещается внутри элемента <system.serviceModel>. Элемент <service> определяет предоставляемые службы. Аналогично, как мы уже видели в коде, служба нуждается в конечной точке, и конечная точка содержит информацию об адресе, связывании и контракте.
<?xml version=”1.0” encoding=”utf-8” ?>
<configuration xmlns=”http://schemas.microsoft.com/.NetConfiguration/v2.0”>
<system.serviceModel>
<services>
<service serviceType=”Wrox.ProCSharp.Indigo.CourseRegistrationService”>
<endpoint address=”http://localhost:9200/CourseRegistrationService”
bindingConfiguration=”CourseRegistrationConfiguration”
bindingSectionName=”wsProfileBinding”
contractType=”Wrox.ProCSharp.Indigo.ICourseRegistration” />
</service>
</services>
<bindings>
<wsProfileBinding>
<binding configurationName=”CourseRegistrationConfiguration”
securityMode=”WSSecurityOverHttp”
reliableSessionEnabled=”true”>
</wsProfileBinding>
</bindings>
</system.serviceModel>
</configuration>
Хостинг
WCF весьма гибок в отношении выбора хоста для запуска службы. Хостом может служить системная служба Windows, приложение COM+, ASP.NET, приложение Windows или простое консольное приложение. Создав собственный хост в виде приложения Windows Forms, вы легко можете создать одноранговое решение.
Следующий пример кода демонстрирует хостинг службы внутри консольного приложения. В методе Main() создается экземпляр ServiceHost<>. После того, как этот экземпляр создан, читается конфигурационный файл приложения для определения связываний. Как мы уже видели, это можно сделать также программно. Далее вызывается метод Open() класса ServiceHost<>, чтобы служба могла принимать запросы клиентов. В консольном приложении нужно уделить внимание тому, чтобы основной поток не был закрыт до закрытия службы. Здесь у пользователя запрашивается команда ее закрытия (нажатием enter).
using System;
using System.ServiceModel;
public class Program
{
public static void Main()
{
using (ServiceHost<CourseRegistrationService> serviceHost =
new ServiceHost<CourseRegistrationService>())
{
serviceHost.Open();
Console.WriteLine(“Служба запущено. Нажмите enter для выхода”);
Console.ReadLine();
serviceHost.Close();
}
}
}
Если служба запущена из приложения Windows Forms, и ее код вызывает методы органов управления Windows Forms, нужно обратить внимание на то, что вызывать методы и свойства органов управления разрешено только тому потоку, в котором они были созданы. В WCF такое поведение легко обеспечить установлением атрибута [ServiceBehavior] свойству RunOnUIThread.
При хостинге в ASP.NET служба получает в свое распоряжение такие средства рабочего процесса ASP.NET, как автоматическая активация, мониторинг состояния и повторное использование процессов.
Для использования хостинга ASP.NET нужно лишь создать файл .svc с декларацией Service, которая будет включать язык и имя служебного класса (в данном случае - Wrox.ProCSharp.WCF.CourseRegistrationService). Вдобавок необходимо специфицировать сборку, содержащую этот класс. Вместо сборки можно указать исходный файл, чтобы скомпилировать его по требованию.
<%@Service language=”C#” class=”Wrox.ProCSharp.Indigo.CourseRegistrationService” %>
<%@Assembly name=”CourseRegistrationService” %>
Клиенты
Клиентское приложение нуждается в прокси-объекте для доступа к службе. Существует два способа создания прокси для клиента:
· Svcutil.exe: Вы создаете прокси класс утилитой SvcUtil. Эта утилита читает метаданные из службы для создания класса прокси.
· Класс ChannelFactory: Этот класс используется прокси, сгенерированным SvcUtil. Однако он также может быть использован для программного создания прокси.
Утилита Svcutil нуждается в метаданных для создания класса прокси. Мы уже видели подобные утилиты: wsdl.exe для Web-служб и soapsuds – для .NET Remoting. Утилита Svcutil может создать прокси по метаданным конечной точки, метаданным сборки, либо документации WSDL и XSD:
svcutil http://localhost:9200/CourseRegistrationService /language:C# /out:proxy.cs
svcutil CourseRegistration.dll
svcutil CourseRegistration.wsdl CourseRegistration.xsd
После этого просто создается экземпляр класса прокси, вызываются его методы и в конце – метод Close():
CourseRegistrationProxy proxy = new CourseRegistrationProxy();
proxy.RegisterForCourse(courseRegistration);
proxy.Close();
Вместо применения сгенерированного класса прокси можно использовать статический метод CreateChannel() класса ChannelFactory. Такое создание прокси удобно в тех случаях, когда метаданные для создания прокси недоступны на момент компиляции. Внутри сгенерированного класса прокси, показанного ранее, метод ChannelFactory.CreateChannel() вызывается в теле конструктора. Метод CreateChannel() возвращает объект канала, который реализует запрошенный контракт службы вместе с информацией об адресе и связывании.
EndpointAddress address =
new EndpointAddress(“http://localhost:9200/CourseRegistrationService”);
WsProfileBinding binding = new WsProfileBinding();
ICourseRegistration proxy =
ChannelFactory.CreateChannel<ICourseRegistration>(address, binding);
proxy.RegisterForCourse(course);
((IChannel)proxy).Close();
Подготовка к WCF
Мы увидели, как могут быть созданы и использованы службы WCF. Однако WCF еще не доступен в релизе .NET 2.0. Пока вы можете наилучшим образом подготовиться к WCF, используя технологии сегодняшнего дня, но имея в виду будущий переход к WCF.
Применение ASP.NET для разработки Web-служб – наилучший путь к WCF. Если требуется больше средств Web-служб, чем доступно в ASP.NET, то можно применить расширение Web-служб WSE (Web Services Enhancement). WSE представляет средства безопасности, настраиваемый хостинг, а также возможность использования канала TCP.
Если нужны такие средства, как автоматические транзакции, пулинг объектов или раздельные процессы, то хорошим выбором будет технология Служб Уровня Предприятия. Скоро мы увидите, как они интегрируются с WCF.
Для разъединенных (автономных) сценариев, когда клиент и сервер могут работать в разное время (например, при использовании ноутбука), следует применять System.Messaging.
Для быстрых коммуникаций между приложениями .NET хорошим выбором может быть .NET Remoting с бинарным форматированием. Однако следует помнить, что это подходит только в тех случаях, когда на обоих концах канала находятся приложения .NET. Технология .NET Remoting не является независимой от платформ.
Посмотрим, как все эти технологии можно будет интегрировать с WCF.
.NET Remoting
Главными особенностями .NET Remoting является возможность применения любого вида приложений в качестве хоста, повышенная скорость коммуникаций по сравнению с Web-службами ASP.NET (при использовании бинарных форматеров), а также возможность работы со статусными и безстатусными объектами. Мы уже видели в этой главе, что WCF поддерживает любые виды хостов и быстрые коммуникации со связками NetProfileXXX.
В .NET Remoting можно создавать компоненты со статусом и без. В терминологии .NET объекты со статусом называются клиент-активируемыми объектами, а без статуса – хорошо известными однократно вызываемыми объектами. «Хорошо известный одиночка» (well-known singleton) – это единственный объект, разделяемый всеми клиентами. При использовании WCF поведение создания экземпляров объектов определяется атрибутом [ServiceBehavior]. Свойство InstanceMode может принимать значения PerCall, PrivateSession, SharedSession и Singleton. PerCall означает, что новый экземпляр создается при каждом вызове метода, PrivateSession говорит о том, что некоторый объект используется внутри сессии, установка значения SharedSession позволяет разделять один объект между несколькими сессиями. Значение Singleton указывает, что создается только один экземпляр, разделяемый всеми клиентами.
|
Типы объектов |
.NET Remoting |
WCF |
|
Статусные |
Клиент-активируемые объекты |
InstanceMode.PrivateSession InstanceMode.SharedSession |
|
Безстатусные |
Хорошо известные, однократно вызываемые |
InstanceMode.PerCall |
|
Одиночки |
Хорошо известные, одиночки |
InstanceMode.Singleton |
[ServiceBehavior(InstanceMode=InstanceMode.PerCall)]
public class CourseRegistration : ICourseRegistration
{
Как выбрать, что использовать сегодня - .NET Remoting или Web-службы ASP.NET? .NET Remoting следует применять для коммуникаций между приложениями .NET на обоих концах канала. .NET Remoting – неподходящий выбор для независимых от платформы служб.
На сегодняшний день не существует планов представления прямой интероперабельности между приложениями .NET Remoting и WCF. Для использования средств WCF вам придется переписать службы .NET Remoting. Если обычно вы разносите функциональность служебного кода в разные классы, это будет нетрудно сделать. В служебных классах нужно будет только исключить наследование от MarshalByRefObject, и добавить необходимые атрибуты. Конфигурационные файлы .NET Remoting могут быть заменены конфигурацией WCF. Это также поможет, если вы используете интерфейсы служебных классов.
Сложнее обстоят дела, если .NET Remoting расширяется за счет применения разъемов (sinks). Не существует простого способа изменить код разъемов для создания промежуточного кода WCF. Модели программирования слишком отличаются. Однако функциональность многих разъемов, которые могут быть реализованы сегодня, также легко доступна в WCF. Такие разъемы не придется подвергать миграции. Что касается других разъемов, функциональность которых отсутствует в WCF, то код следует разнести по отдельным классам, чтобы можно было повторно использовать хотя бы часть его.
Если нет необходимости в использовании новых средств WCF в приложениях .NET Remoting, то код .NET Remoting может исполняться бок о бок с WCF.
Web-службы ASP.NET
Технология Web-служб ASP.NET позволяет сегодня разрабатывать независимые от платформы службы. Применение ASP.NET для создания Web-служб – хороший способ подготовиться к будущему применению WCF:
Web-службы ASP.NET и WCF могут взаимодействовать напрямую. WCF-клиент может обращаться к Web-службам ASP.NET, и прокси Web-служб .NET 2.0 могут иметь доступ к службе WCF. Для такой интероперабельности в WCF следует использовать связывание BasicProfile.
Перенос Web-службы ASP.NET в WCF также не представляет собой сложную задачу. WCF может использовать ASP.NET в качестве хоста. Для этого всего лишь нужно создать файл .svc, как было показано раньше. Атрибуты [WebMethod] необходимо заменить на [OperationContract]. При необходимости могут быть добавлены другие атрибуты, - вместе с ними вы добавите дополнительные средства WCF к своим службам.
Службы Уровня Предприятия
Если вы разрабатываете служебные компоненты сегодня, то существует отличный путь миграции к WCF. Не изменяя служебных компонентов, можно создавать передний план WCF, который предоставит доступ к ним. К тому же под видом службы WCF COM-клиент может обращаться к службам WCF.
С помощью утилиты ComSvcConfig можно создать передний план WCF к приложению Служб Уровня Предприятия:
ComSvcConfig add /application:OrderControlComponent
/interface:Wrox.ProCSharp.EnterpriseServices.OrderControl, IOrderControl
/hosting:was /webDirectory:OrderControl /mex
Опция /application указывает приложение COM+, /interface – интерфейс приложения, которое должно быть доступно в виде Web-службы. Опция /hosting определяет процесс, используемый в качестве хоста. Возможные значения этой опции: was и complus. was использует виртуальный директорий IIS, а complus – в качестве процесса хоста использует сам процесс приложения COM+. Установка /webDirectory указывает виртуальный директорий службы. Этот директорий может быть конфигурирован в IIS до создания службы WCF. Опция /mex указывает необходимость создания метаданных конечной точки, которая может быть использована клиентами WCF для чтения метаданных службы.
Другой обходной путь заключается в применении клиентов COM для доступа к службам WCF. В этом случае код клиентского прокси создается утилитой svcutil:
svcutil “http://localhost/OrderControl/OrderControl.svc” /language:c# /out:proxy.cs
Полученный в результате файл proxy.cs должен быть размещен в сборке, оформленной строгим образом с атрибутом [ComVisible]:
[assembly: ComVisible(true)]
Для этой сборки должен быть создана и конфигурирована утилитой regasm «обертка» COM Callable Wrapper (CCW) (см. главу 33), а сама сборка должна быть инсталлирована в GAC (см. главу 15). Когда это будет сделано, то COM-клиент сможет обращаться к WCF под видом клиента WCF. Следующий код представляет пример клиентского приложения VBScript, использующего маскировку под WCF:
Set proxy = GetObject(
“service:address=http://localhost/OrderControl/OrderControl.svc,
binding=wsProfileBinding, contract={05AFF608-AA50-444a-B85B-D5E4248956DA}”)
Как видим, WCF и Службы Уровня Предприятия имеют великолепные возможности для интероперабельности. То же самое можно сказать об Очередях Сообщений.
Очереди Сообщений
Очереди Сообщений – это технология, которая может применяться в автономных (отключенных) средах. Нет необходимости в одновременной работе клиентского и серверного приложений (что необходимо при асинхронном программировании). Здесь приложение-отправитель пишет сообщения в очередь, а приложение-приемник, которое запускается позднее, читает их оттуда.
Клиентское приложение WCF может писать сообщения в очередь, которые читаются приложениями, использующими классы из пространства имен System.Messaging (см. главу 31). Другой вариант заключается в использовании WCF, как службы, с клиентским приложением, использующим классы пространства имен System.Messaging. В обоих сценариях применяется связка MsmqIntegration, не поддерживающая аутентификацию.
Если и посылающее и принимающее приложения применяют WCF, может быть использована связка NetProfileMsmq, которая также представляет интеграцию средств защиты с Очередями Сообщений.
Итоги
В этой главе мы рассказали о том, как подготовиться к технологии будущего в области коммуникаций. Ко многим бизнес-решениям на основе Web-служб предъявляются требования обеспечения безопасности, надежности, транзакций и производительности. WCF – технология, реализующая все эти требования.
WCF может сочетаться со средствами .NET Remoting, Web-служб ASP.NET, Служб Уровня Предприятий и Очередями Сообщений. Она представляет одну и ту же программную модель для использования всех этих средств. К тому же WCF может быть легко интегрирована с существующими технологиями.