Windows communication foundation что такое

From Wikipedia, the free encyclopedia

Windows Communication Foundation (WCF)

Original author(s)	Microsoft
Developer(s)	.NET Foundation
Initial release	November 21, 2006; 16 years ago
Stable release	v3.4.0 / August 18, 2022; 13 months ago
Repository	github.com/dotnet/wcf
Written in	C#
Operating system	Linux, macOS, Windows
Platform	.NET Framework, .NET
Predecessor	Web Services Enhancements
Type	Software framework
License	MIT License
Website	docs.microsoft.com/en-us/dotnet/framework/wcf/index

The Windows Communication Foundation (WCF), previously known as Indigo, is a free and open-source runtime and a set of APIs in the .NET Framework for building connected, service-oriented applications.^[1][2]

.NET Core 1.0, released 2016, did not support WCF server side code. WCF support was added to the platform with support for .NET Core 3.1, .NET 5, and .NET 6 in 2022.^[3]

The architecture[edit]

WCF is a tool often used to implement and deploy a service-oriented architecture (SOA).
It is designed using service-oriented architecture principles to support distributed computing where services have remote consumers. Clients can consume multiple services; services can be consumed by multiple clients. Services are loosely coupled to each other. Services typically have a WSDL interface (Web Services Description Language) that any WCF client can use to consume the service, regardless of which platform the service is hosted on. WCF implements many advanced Web services (WS) standards such as WS-Addressing, WS-ReliableMessaging and WS-Security. With the release of .NET Framework 4.0, WCF also provides RSS Syndication Services, WS-Discovery, routing and better support for REST services.

Endpoints[edit]

A WCF client connects to a WCF service via an endpoint. Each service exposes its contract via one or more endpoints. An endpoint has an address (which is a URL specifying where the endpoint can be accessed) and binding properties that specify how the data will be transferred.

The mnemonic «ABC» can be used to remember address/binding/contract. Binding specifies what communication protocols are used to access the service, whether security mechanisms are to be used, and the like. WCF includes predefined bindings for most common communication protocols such as SOAP over HTTP, SOAP over TCP, and SOAP over Message Queues, etc. Interaction between WCF endpoint and client is done using a SOAP envelope. SOAP envelopes are in simple XML form, which makes WCF platform-independent. When a client wants to access the service via an endpoint, it not only needs to know the contract, but it also has to adhere to the binding specified by the endpoint. Thus, both client and server must have compatible endpoints.

With the release of the .NET Framework 3.5 in November 2007, Microsoft released an encoder that added support for the JSON serialization format to WCF.^[4]

Behaviors[edit]

Behaviors are types that modify or extend service or client functionality. Behaviors allow the developer to create custom processing, transformation, or inspection that is applied to messages as they are sent or received. Some examples of uses for behaviors are:

• Controlling whether metadata is published with a service.
• Adding security features to a service, such as impersonation, authorization,^[5] or managing tokens
• Recording information about messages, such as tracking, tracing, or logging
• Message or parameter validation
• Invoking all additional operations when messages are received—such as notifying users when certain messages arrive

Behaviors implement the IServiceBehavior interface for service extensions, the IEndpointBehavior for endpoints, the IContractBehavior interface for service contracts, or the IOperationBehavior for operations. Service behaviors are used for message processing across a service, rather than processing that would be specific to a single operation.

Interoperability[edit]

WCF supports interoperability with WCF applications running on the same Windows machine or WCF running on a different Windows machines or standard Web services built on platforms such as Java running on Windows or other operating systems. In addition to SOAP, WCF 4 supports non-SOAP XML, RSS, JSON, and binary formats for external communication via HTTP or HTTPS.^[6]

See also[edit]

• Microsoft Connected Services Framework
• Web Services Enhancements
• Service Component Architecture (SCA) and Service Data Objects (SDO), which are alternatives to WCF in the Java world standardized by OASIS.
• WCF Data Services

References[edit]

• «What Is Windows Communication Foundation». MSDN. Microsoft. 10 August 2023.
• «Windows Communication Foundation Architecture». MSDN. Microsoft. 15 September 2021.

Further reading[edit]

• Craig McMurtry, Marc Mercuri, and Nigel Watling: Microsoft Windows Communication Foundation: Hands-On, SAMS Publishing, May 26, 2004, ISBN 0-672-32877-1
• Steve Resnick, Richard Crane, Chris Bowen: Essential Windows Communication Foundation (WCF): For .NET Framework 3.5, Addison-Wesley, February 11, 2008, ISBN 0-321-44006-4
• Craig McMurtry, Marc Mercuri, Nigel Watling, Matt Winkler: Windows Communication Foundation Unleashed (WCF), Sams Publishing, March 6, 2007, ISBN 0-672-32948-4
• Juval Löwy: Programming WCF Service, O’Reilly Media, Inc., February 20, 2007, ISBN 0-596-52699-7
• Pablo Cibraro, Kurt Claeys, Fabio Cozzolino, Johann Grabner: Professional WCF 4: Windows Communication Foundation with .NET 4, Wrox, June 15, 2010, ISBN 0-470-56314-1
• Andrew Zhu: Microsoft Windows Workflow Foundation 4.0 Cookbook:Chapter 3, Packt Publishing, September 2010, ISBN 978-1-84968-078-3

External links[edit]

• Windows Communication Foundation, MSDN Windows Communication Foundation portal.
• MSDN Library: Windows Communication Foundation
• WCF Security Guide Archived 2011-03-14 at the Wayback Machine, Microsoft Patterns & Practices — Improving Web Services Security: Scenarios and Implementation Guidance for WCF. Released Aug 1, 2008.
• Understanding WCF Services in Silverlight 2 Archived 2011-03-12 at the Wayback Machine — In depth explanation of WCF services for Silverlight clients.
• David Chappell: «Introduction to WCF» and «Dealing with Diversity», two papers covering WCF. November 2007.
• Getting Started with WCF RIA Services — part 1 of the series articles on WCF RIA Services

Windows Communication Foundation (WCF) — это средство, разработанное компанией Microsoft, которое предоставляет разработчикам возможность создавать современные, распределенные приложения для операционной системы Windows. WCF предоставляет набор инструментов и библиотек, которые позволяют разработчикам обмениваться данными и взаимодействовать с другими системами через различные протоколы и технологии.

Одной из основных функций WCF является поддержка сервисно-ориентированной архитектуры (SOA), которая позволяет разбить приложение на отдельные компоненты, которые могут быть развернуты на разных узлах сети. Эти компоненты могут взаимодействовать друг с другом через WCF, обмениваясь сообщениями.

WCF поддерживает различные протоколы, такие как HTTP, TCP, Named Pipes и другие, а также различные форматы сообщений, включая XML и JSON. Это позволяет разработчикам выбирать наиболее подходящие протоколы и форматы для конкретных потребностей и условий развертывания приложения.

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

Windows Communication Foundation — мощная и гибкая библиотека, которая позволяет разработчикам легко создавать и развертывать распределенные приложения для Windows. Она предоставляет широкий набор функций и гибких настроек для обмена данными и взаимодействия между компонентами приложений.

Основные понятия

Основными понятиями в WCF являются:

• Служба (Service) — это основной компонент в WCF, который предоставляет функциональность, доступную для удаленного вызова. Служба может быть реализована в виде класса, который содержит методы, доступные для клиента. Службы могут быть развернуты как локально, так и удаленно, и могут быть вызваны через сеть.
• Контракт (Contract) — определяет набор операций, которые может выполнить служба. В WCF контракты могут быть разделены на три типа: контракт службы (Service Contract), контракт данных (Data Contract) и контракт сообщения (Message Contract). Контракты обеспечивают единый интерфейс для взаимодействия между клиентом и службой.
• Клиент (Client) — это приложение или компонент, который обращается к службе WCF для выполнения операций. Клиент может быть разработан на платформе Windows или любой другой платформе, которая поддерживает стандарты взаимодействия с WCF.
• Привязка (Binding) — определяет способ взаимодействия между клиентом и службой. В WCF доступно несколько типов привязок, которые определяют протоколы, транспорты и кодировки данных, используемые для обмена сообщениями.
• Канал (Channel) — это абстракция, которая представляет собой протокол коммуникации между клиентом и службой в WCF. Каналы отвечают за отправку и получение сообщений между клиентом и службой, а также за обработку различных аспектов, таких как кодирование, сериализация и транспортировка данных.

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

Архитектура Windows Communication Foundation

Архитектура WCF основана на модели сервис-ориентированной архитектуры (Service Oriented Architecture, SOA). Согласно этой модели, приложения представляют собой набор сервисов, которые могут быть запущены на разных компьютерах и взаимодействуют между собой посредством обмена сообщениями.

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

Для обеспечения надежной коммуникации между клиентом и сервисом WCF использует язык описания сервисов (Service Description Language, SDL), который определяет формат сообщений, используемых для обмена данными, а также типы данных, которые могут быть переданы по сети.

Основой архитектуры WCF являются протоколы связи, которые определяют, как данные будут передаваться между клиентом и сервисом. WCF поддерживает различные протоколы, включая HTTP, TCP, WS-Http и прочие. Это позволяет использовать WCF для создания приложений, работающих как в Интернете, так и в локальных сетях.

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

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

Основные преимущества

Библиотека Windows Communication Foundation (WCF) предлагает несколько основных преимуществ, которые делают ее одной из наиболее гибких и мощных технологий разработки распределенных приложений:

• Гибкость: WCF поддерживает разнообразные архитектурные шаблоны и обеспечивает гибкую модель разработки приложений. Он позволяет разработчикам создавать приложения, которые могут работать в различных средах, таких как ОС Windows, веб-службы, сервисы сообщений и другие.
• Масштабируемость: WCF поддерживает различные протоколы связи, включая HTTP, TCP, Named Pipes и другие, что позволяет разработчикам создавать приложения с различными уровнями масштабируемости.
• Безопасность: WCF предлагает мощные механизмы защиты и аутентификации, которые позволяют разработчикам создавать безопасные распределенные приложения. Он поддерживает различные методы шифрования и подписи сообщений для обеспечения безопасности данных.
• Взаимодействие: WCF позволяет различным приложениям взаимодействовать друг с другом, независимо от платформы и языка программирования. Это обеспечивает интероперабельность между различными технологиями.
• Управление ошибками: WCF предоставляет механизмы обработки ошибок и исключений, которые помогают разработчикам создавать надежные приложения. Он также поддерживает контракты по обнаружению и передаче ошибок, что упрощает отладку и управление ошибками.

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

Примеры использования

Windows Communication Foundation (WCF) предоставляет мощные инструменты для разработки распределенных приложений. Вот несколько примеров использования WCF:

1. Клиент-серверное взаимодействие:

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

2. Создание службы обмена сообщениями:

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

3. Поддержка различных протоколов:

WCF поддерживает различные протоколы связи, такие как TCP, HTTP, Named Pipes и другие. Это позволяет приложениям взаимодействовать через различные протоколы в зависимости от их потребностей.

4. Шифрование и аутентификация данных:

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

5. Разработка распределенных приложений:

WCF позволяет разрабатывать распределенные приложения, которые могут работать на разных компьютерах или даже в разных доменах. Например, вы можете создать клиент-серверное приложение, где сервер находится на одном компьютере, а клиенты – на других компьютерах, подключенных к сети.

Это лишь некоторые примеры использования Windows Communication Foundation. Библиотека WCF предоставляет много возможностей для разработки сложных распределенных приложений, обмена данными и обеспечения безопасности.

Недавно на rsdn.ru был задан интересный вопрос, что такое WCF? Вопрос весьма интересный, на который ответить в форуме достаточно сложно, но я все же постарался это сделать, а здесь я хочу привести несколько облагороженный вариант своего ответа.

Общие сведения

Если в двух словах, то WCF (a.k.a. Windows Communication Foundation) — это очередной фреймворк для построения распределенных приложений и межпроцессного взаимодействия, который является логическим развитием предыдущих подобных технологий компании Майкрософт, в частности Веб-сервисов, .Net Remoting и DCOM. И если предшественники были заточены на выполнение какого-то конкретного круга задач, то WCF — это скорее мультипарадигменная технология, вобравшая в себе все лучшее от своих предшественников, добавив при этом, конечно же, кое-каких собственных проблем.

Существенным отличием WCF от .Net Remoting является то, что WCF — это, прежде всего, технология для построения сервис-ориентированной архитектуры приложений (SOA — Service-Oriented Architecture), что позволяет абстрагироваться от конкретной технологи, на которой этот сервис реализован и пользоваться им из других приложений, написанных на любой другой платформе, языке, технологии; главное, чтобы реализация клиента отвечала определенным правилам. Кроме того, логика самого сервиса и его реализация полностью отделена от коммуникационной составляющей, и мы можем декларативно изменять способ взаимодействия с сервисом путем изменения конфигурационного файла. Мы можем изменить протокол взаимодействия, адрес, настроить максимальное количество подключений, ограничить размер пакетов и тайм-аут подключения к сервису, тайм-аут выполнения операции, надежность доставки и многое другое.

Нужно отметить, что подобное декларативная настройка присутствовала и в .Net Remoting, там мы тоже могли без перекомпиляции приложения изменить протокол взаимодействия и многие другие параметры. Главное отличие WCF от своего главного предшественника (да, я все о том же .Net Remoting) заключается в том, что WCF «не выносит свой сор из избы» и не показывает наружу никакие платформенно зависимые детали реализации сервиса, такие как сборки, конкретные классы сервиса, типы аргументов или исключения. Вместо этого сервис представляет собой группу операций, определенных в некотором интерфейсе, которые получают некоторые абстрактные входные/выходные параметры; все это дело описывается с помощью WSDL (Web Service Description Language) и может быть выставлено наружу через, так называемые mex-endpoints (Metadata Exchange Endpoints). Это позволяет получить «метаданные» сервиса подключившись к этому интерфейсу, получить описание сервиса и всех его операций и сгенерировать соответствующий прокси класс для заданного языка или платформы. Именно это позволяет написать сервис с помощью WCF, а использовать его из Java/Python/Ruby и чего угодно еще.

Именно эта сервис-ориентированность делает WCF во многих вопросах не похожей на обыкновенный механизм RPC, привычный многим по использованию .Net Remoting. Поскольку все описание сервиса мы можем получить через WSDL (включая типы, используемые для параметров метода), в WCF существует такое понятие как эквивалентность типов: два типа являются эквивалентными и могут использоваться в одной и той же операции сервиса, если они содержат одинаковое представление на уровне канала передачи данных. Таким образом, если речь идет о взаимодействии WCF-WCF, то на стороне клиента мы можем использовать тип Point с двумя свойствами X и Y, а на стороне сервиса использовать другой тип, определенный в другой сборке, с аналогичным именем, и аналогичными именами и типами свойств. При этом мы можем спокойно передавать на стороне клиента экземпляр одного типа, а на стороне сервиса получить экземпляр другого типа (и это совершенно естественно, помните, наш клиент и сервис могут быть написаны на разных платформах, так что, здесь главное, чтобы сервис и клиент могли понимать друг друга на уровне сообщений).

Прозрачность местоположения

В девяностых и начале двухтысячных годов была безумная мысль создать инфраструктуру, которая бы скрыла тот факт, что объект является удаленным. Так в DCOM и .Net Remoting было такое понятие как «прозрачность местоположения» (location transparency), которое означало, что вам, как разработчику, не стоит задумываться над тем, является ли объект, с которым вы работаете, локальным или удаленным. Поэтому при создании экземпляра объекта мы не знали, является ли этот объект прокси к удаленному объекту или он полностью «сидит» в памяти нашего процесса (на самом деле в .Net Remoting это можно было узнать, вызвав RemotingServices.IsTransparentProxy, но думаю, что идея понятна). Тогда это казалось отличной идеей, но практика показала, что пользовательский код должен четко знать, что он работает с удаленным объектом, поскольку это упрощает разделение коммуникационных ошибок от ошибок бизнес-логики, генерируемых сервисом или клиентом. WCF не скрывает тот факт, что вы работаете с прокси, и вы можете спокойно отделить коммуникационные ошибки (Communication Exceptions), от ошибок бизнес-логики, произошедших в сервисе/клиенте. Все некоммуникационные ошибки также являются частью протокола взаимодействия между клиентом и сервисом (такая себе спецификация исключений), они четко описываются в виде Fault Contract-ов и также «выставляются наружу» через WSDL (ведь мы можем работать с платформой, у которой исключений может не быть вообще).

Если вдаваться в некоторые специфические различия между WCF и .Net Remoting, то нельзя обойти вниманием механизм обратных вызовов, который претерпел колоссальные изменения. Так, в WCF интерфейс обратного вызова также является частью контракта сервиса и задается в нем непосредственно, это дает возможность в каждом вызове сервиса получить интерфейс обратного вызова, в случае необходимости сохранить его и потом вызвать метод этого интерфейса. Это поддерживается не всеми коммуникационными протоколами (поскольку некоторые протоколы являются по своей сути однонаправленными) и тогда, в случае несовместимости, вы получите ошибку в процессе создания экземпляра сервиса.

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

Использование WCF в виде RPC

WCF – это отличная технология для построения сервис-ориентированных приложений, что накладывает ряд ограничений на ее использование. Так, например, WCF (точнее сервисы) не поддерживают перегрузку методов (вы не можете использовать два метода с одинаковыми именами, но разным набором параметров), а также вы не можете использовать полиморфизм: нельзя определить метод сервиса, который принимает (или возвращает) переменную базового типа и передавать в него (или возвращать из него) экземпляры производных типов. Обойти это ограничение можно указав перечень «известных типов» (Known Types) (*), которые также могут быть получены через WSDL. Все это делает WCF не лучшим кандидатом, если вам нужен старый добрый RPC, к которому вы могли привыкнуть при работе с ремоутингом.

Проблемы с известными типами связаны с тем, что сериализатор, используемый в WCF по умолчанию (он называется DataContractSerializer) не добавляет в выходной поток информации о CLR типе и это естественно, поскольку «с другой стороны» может находиться система, которая об этой самой CLR не имеет ни малейшего понятия. Однако WCF содержит и другой тип сериализатора, NetDataContractSerializer, который является полной копией стандартного сериализатора, однако помимо всего прочего он добавляет полное имя типа в сериализованный поток байтов. Это сводит на нет всю сервис-ориентированную кросс-платформенность, но позволяет использовать любые сериализируемые классы в виде аргументов и возвращаемых значений и не заботиться ни о каких известных типах. (Если типы аргументов и возвращаемых значений использовались в ремоутинге и были помечены атрибутом Serializable, то их можно будет использовать и в WCF без изменений, так что переход от одной технологии к другой будет весьма безболезненным). Это позволяет использовать WCF в виде RPC, причем сменить сериализатор можно, опять таки декларативно, из конфигурационного файла приложения (**).

«Слоеная архитектура» WCF

Большинство подобных технологий для построения распределенных приложений (такие как WCF или .Net Remoting) строятся по принципу слоеного пирога (ага, сетевую модель OSI, надеюсь, еще не забыли), когда каждый слой отвечает за свой конкретный уровень абстракции и не знает ничего о нижележащих уровнях. Если говорить коротко, то вся инфраструктура WCF состоит из двух главных уровней: (1) Service Model Layer и (2) Channel Layer. Первый уровень ближе относится к самому сервису и клиенту и отвечает за преобразования метода и его параметров в сообщение для передачи более низкому канальному уровню. Канальный уровень (Channel Layer) инкапсулирует в себе канал передачи данных (спасибо, кэп), которых может быть великое множество: каналы, использующие в качестве транспорта TCP, Http, Named Pipes и т.д. Каждый из этих уровней содержит несколько подуровней, и вы можете вклиниться в каждый из них для каких-то собственных нужд.

Например, вы можете валидировать параметры методов обобщенным образом: предположим, вам всегда нужно, чтобы объекты определенного типа, используемые в десятке методов сервиса, обладали определенной характеристикой, вместо вызова метода валидации из всех методов сервиса, вы можете написать соответствующий «перехватчик» и обработать это один раз. Вы можете самостоятельно создавать WCF сообщения, изменять существующие (добавлять собственное шифрование, добавлять дополнительную информацию в заголовок сообщения или в его теле), вы можете добавлять свои собственные каналы, которые, будут работать по протоколу UDP с вашей *самописной* системой по вашему *самописному* коммуникационному протоколу. Вы можете добавлять обобщенные каналы связи для поддержки, например, UDP, поскольку такого канала нет в WCF «из коробки» и т.д. Все это может звучать несколько сложно, но если идти от простых задач к более сложным, то страшного в этом ничего нет.

Выводы

Что можно сказать в заключении? Если на платформе .Net вам понадобиться некоторый вид распределенного или межпроцессного взаимодействия, то первое на что стоит посмотреть — это WCF. Даже из коробки эта штука поддерживает большую часть функционала, который вам может понадобиться, а если же этого не произойдет, то вы всегда сможете его расширить по мере необходимости.

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

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

Как я уже упомянул, по WCF существует множество книг, но я бы рекомендовал обратить внимание, как минимум на две:

Книга Джувела Лёве позволит вам понять, как использовать существующие возможности WCF, а книга Джастина Смита – понять, как эти возможности расширить. Так что, эти книги – не конкуренты друг другу, скорее они дополняют друг друга, покрывая разные аспекты использования этой технологии. (Кстати, книга Лёве вышла в 2010-м году и отражает те новшества, которые появились в .Net Framework 4.0, а предыдущее издание издавалось издательством Питер на русском языке).

Что касается статей по WCF, особенно по теме «расширябельности», то, прежде всего, стоит обратить внимание на статьи Аарона Сконнарда (Aaron Skonard) в MSDN Magazine, и прежде всего на следующие:

2. Другие статьи Аарона в MSDN Magazine из серии Service Station.

————————————

(*) Об «известных типах» я неоднократно писал в блоге, но проще почитать об этом в одной статье, опубликованной на rsdn.ru: «Известные типы (Known Types) в WCF».

(**) Если вы хотите задать использование NetDataContractSerializer, в качестве сериализатора вашего сервиса в конфигурационном файле приложения, вам придется немного попотеть, поскольку эта функциональность «из коробки» не поддерживается. За подробностями, прошу к другой моей статье: «Декларативное использование NetDataContractSerializer-а»

Windows Communication Foundation (WCF) – это фреймворк от компании Microsoft, который предоставляет набор инструментов и технологий для создания и развертывания сетевых приложений. WCF поддерживает различные протоколы, такие как HTTP, TCP, MSMQ и другие. Одним из важных аспектов WCF является возможность запуска и использования нескольких протоколов одновременно.

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

Для активации Non HTTP Activation необходимо выполнить несколько простых шагов. В первую очередь, пользователь должен открыть «Панель управления», затем выбрать «Программы и компоненты» и «Включение или отключение компонентов Windows». Там необходимо найти раздел «Windows Communication Foundation» и убедиться, что отмечена опция «Non-HTTP Activation». Если она не отмечена, нужно отметить ее и нажать «ОК». После этого будет произведена активация компонента.

Когда компонент Non HTTP Activation установлен и активирован, разработчики получают возможность использовать WCF с любыми поддерживаемыми протоколами, включая TCP, MSMQ и др. Это позволяет создавать мощные и гибкие сетевые приложения, работающие в различных средах и взаимодействующие с разными системами.

Non HTTP Activation является важной частью WCF, которая расширяет возможности разработчиков и позволяет использовать данную технологию в широком спектре сценариев. Активируйте компонент Non HTTP Activation на вашей системе, чтобы использовать WCF с протоколами, отличными от HTTP, и воплотите свои идеи в современные и мощные сетевые приложения.

Windows Communication Foundation Non HTTP Activation

Для использования Windows Communication Foundation Non HTTP Activation необходимо установить соответствующий компонент Windows. Это можно сделать через «Панель управления» -> «Программы и компоненты» -> «Включение или отключение компонентов Windows». Затем необходимо отметить «Windows Communication Foundation Non-HTTP Activation».

После установки компонента Windows Communication Foundation Non HTTP Activation, приложения будут иметь возможность использовать не только HTTP для взаимодействия между компонентами, но и другие протоколы.

При разработке приложения, которое будет использовать Windows Communication Foundation Non HTTP Activation, необходимо указать используемый протокол в соответствующем разделе конфигурации. Например, для использования TCP, необходимо указать следующее:

Конфигурация	Значение
binding	netTcpBinding
protocol	tcp

Таким образом, Windows Communication Foundation Non HTTP Activation позволяет разработчикам создавать приложения, которые могут использовать различные протоколы для общения между компонентами и службами. Это обеспечивает большую гибкость и расширяемость в разработке приложений на платформе Windows.

Определение и назначение

WCF Non HTTP Activation позволяет разработчикам создавать и использовать службы WCF для обмена данными между приложениями, используя протоколы, отличные от HTTP. Вместо использования стандартного протокола HTTP, WCF Non HTTP Activation позволяет обмен данными через другие протоколы, такие как TCP, Named Pipes и MSMQ.

WCF Non HTTP Activation занимается активацией и управлением служб WCF, а также обеспечивает механизмы передачи сообщений между клиентом и службой. Это позволяет разработчикам создавать распределенные приложения, которые могут быть развернуты на разных машинах и взаимодействовать друг с другом.

Основная цель WCF Non HTTP Activation состоит в облегчении разработки распределенных приложений на платформе Windows, предоставляя удобный и гибкий способ обмена данными между приложениями, а также развертывания и управления службами.

Преимущества использования

Windows Communication Foundation Non HTTP Activation предоставляет несколько преимуществ, которые делают его полезным инструментом для разработчиков и архитекторов приложений. Вот некоторые из этих преимуществ:

1. Разнообразность протоколов:

WCF Non HTTP Activation позволяет использовать различные протоколы для обмена данными между клиентами и сервисами, включая TCP, Named Pipes и другие. Это обеспечивает большую гибкость и возможность выбора наиболее подходящего протокола для конкретного сценария.

2. Высокая производительность:

Использование WCF Non HTTP Activation позволяет добиться более высокой производительности в сравнении с HTTP-протоколом. Низкоуровневые протоколы, такие как TCP и Named Pipes, обычно имеют меньшую нагрузку на сеть и обеспечивают более быструю передачу данных.

3. Поддержка безопасности:

WCF Non HTTP Activation предоставляет возможности для обеспечения безопасности и защиты данных во время их передачи по сети. Это включает различные механизмы авторизации, аутентификации и шифрования, которые позволяют создавать безопасные взаимодействия между клиентами и сервисами.

4. Возможность работы в локальной сети:

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

5. Расширяемость и гибкость:

WCF Non HTTP Activation предоставляет множество возможностей для настройки и расширения функциональности. Разработчики могут создавать свои собственные каналы, привязки и поведения, чтобы адаптировать WCF под свои конкретные потребности и требования приложения.

Все эти преимущества делают Windows Communication Foundation Non HTTP Activation мощным инструментом для разработки приложений, обеспечивающих эффективное и безопасное взаимодействие между клиентами и сервисами.

Как использовать

Чтобы использовать Windows Communication Foundation Non HTTP Activation, необходимо выполнить следующие шаги:

1. Установите необходимые компоненты .NET Framework, включая Windows Communication Foundation (WCF).
2. Откройте файл конфигурации вашего приложения (обычно это файл с расширением .config).
3. Добавьте следующий код в раздел <system.serviceModel> внутри файла конфигурации:

<bindings>
<netNamedPipeBinding>
<binding name="netNamedPipeBindingConfig" />
</netNamedPipeBinding>
</bindings>
<services>
<service name="YourServiceName">
<endpoint address="" binding="netNamedPipeBinding" contract="YourContractName" />
<host>
<baseAddresses>
<add baseAddress="net.pipe://localhost/YourServiceName" />
</baseAddresses>
</host>
</service>
</services>

Здесь «YourServiceName» и «YourContractName» должны быть заменены на фактические имена вашего сервиса и контракта.

1. В вашем коде приложения создайте экземпляр класса ServiceHost и вызовите метод Open() для запуска сервиса.
2. Теперь вы можете обращаться к вашему сервису через протокол Named Pipes, используя адрес «net.pipe://localhost/YourServiceName».

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