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

Начнем мы знакомство с такого улучшения как упрощенная конфигурация.

Endpoint по умолчанию - позволяет не прописывать явно в секции <configuration> никаких конечных точек (endpoint).

ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService),
    new Uri("http://localhost/CalculatorService"), 
    new Uri("net.tcp://localhost/CalculatorService"));
serviceHost.Open();

Console.WriteLine("WCF Service is running.");
Console.WriteLine("Press <ENTER> to terminate service.");
Console.ReadLine();

serviceHost.Close();

<configuration>
</configuration>

WCF 4.0 автоматически сформирует конечную точку (endpoint) и присвоит ей соответствующие параметры, в частности, сопоставит схему http c BasicHttpBinding, а net.tcp - c NetTcpBinding. При это файл web.config не содержит никаких настроек, тэг <service> (и его подчиненные тэги - <endpoint>) в нем отсутствует.

Binding/behaivor по умолчанию (nameless behaivor) - позволяют сервису наследовать определенные по умолчанию привязки (binding) и поведения (behaivor), эти привязки и поведения определены на более высоком уровне иерархии (machine.config > rootweb.config > web.config и т.д.), что позволяет так же создавать гибкую иерархическую модель наследования настроек.

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="" maxReceivedMessageSize="9999999">
          <readerQuotas maxArrayLength="9999999"/>
        </binding>
      </basicHttpBinding>      
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
</system.serviceModel>

Для того чтобы применить поведение (behaivor) по умолчанию необходимо либо оставить его атрибут name незаполненным, либо пропустить его в определении.

ProtocolMapping - определяет сопоставление привязки (binding) и схемы/протокола (например, HTTP или NET.TCP ), которое применяется по умолчанию. Если обратиться к первому примеру (Endpoint по умолчанию), то имеено за счет ProtocolMapping для cхемы http использовался BasicHttpBindi...

WCF & WSE 2.0

Ответ простой: использовать WSE 3.0, либо настроить custombinding в WCF. Почему? WCF поддерживает только WS-Security 1.1. WSE 3.0 реализует WS-Security 1.0 и WS-Security 1.1, а WSE 2.0 только WS-Security 1.0.

WCF & Java

Организация взаимодействия WCF и Java.

Ответ: убедитесь, что Action Header (приходящее от Java) не является пустым, либо установите в WCF атрибут ServiceBehavior – AddressFilterMode.

Обычные WCF сервисы (SOAP) поддерживают множество различных механизмов аутентификации/авторизации: Windows, сертификаты, SAML токены и т.п. Подключение любого из этих механизмов не займет у разработчика много времени. В случае же с WCF REST сервисами ситуация немного иная, в первую очередь, за счет того, что и логика общения по REST другая. REST позиционируется как более «легковесный/простой» (по сравнению с SOAP) способ построения веб-сервисов. При этом необходимость аутентифицировать и авторизовать пользователя так же актуальная и для REST. Задача аутентификации/авторизации может быть реализована, например, за счет интеграции с ASP.NET (aspNetCompatibilityEnabled=true). Очевидно, что в этом случае требуется IIS и ASP.NET, а так же придерживаться логики механизмов безопасности, определенных на уровне ASP.NET.

Помимо вышеописанного способа есть еще один вариант - OAuth протокол, вернее OAuth WRAP (Web Resource Authorization Protocol).

«OAuth - это открытый протокол авторизации, который позволяет предоставить третьей стороне доступ к защищенным ресурсам пользователя, без необходимости передавать ей (третьей стороне) логин и пароль.» [wikipedia.com]

Логика доступа к защищенным ресурсам с использование WRAP следующая:

1. Клиент получает токен авторизации (Access Token) у доверенного источника (Trusted Authority) - сервера авторизации (Authorization Server). Этот токен содержит авторизационные разрешения и подписывается.
   Разумееется, что при получении токена клиент должен пройти аутентификацию на стороне сервера авторизации, обычно для этого используется HTTPS протокол.
2. REST сервис проверяет, что токен выдан именно доверенным сервером авторизации (Authorization Server) и предоставляет клиенту доступ в соответствии с разрешениями, указанными в токене.

Важно заметить, что токент авторизации может представляться в любом формате (разумеется, что сервис авторизации и конечный REST сервис должны поддерживать и понимать этот формат), например, Simple Web Token (SWT), JSON Web Token или SAML. Именно в этом и заключается отличие WRAP - в нем нет жестких требований или ограничений к механизму обмена токенами и подписи токенов.

Так как мы имеем дело с REST сервисом, то токен может быть передан сервису, например, в строке URL или в заголовке сообщения (Authorization: WRAP access_token="<&>"; WWW-Authenticate: WRAP).

Хороший пример использования SWT токена для REST сервисов приведен в статье "Integrating Simple Web Tokens (SWT) with WCF REST Services using WIF".

Если запустить приведенный пример и в...

Code-First vs. Schema-First

В предыдущих постах я немного рассказывала об интероперабильности в WCF. Большинство описанных проблем интеграции касались особенностей/тонкостей и т.п. формирования WSDL/XSD сервиса.

Стандартный подход, к которому мы привыкли: описывается программно интерфейс/реализация сервиса, после чего автоматически генерируется WSDL файл. Помимо данного подхода, существует еще один, противоположный, когда код формируется на основе описания поведения сервиса (т.е. сначала WSDL/XSD). Для первого варианта в Visual Studio есть встроенные средства и механизмы, а вот для второго - есть специальный аддон к Visual Studio - WSCF.blue. На самом деле, для генерировать код сервиса на основе его описания можно и с помощью svcutil, но это потребует значительно больших усилий, т.к. утилита svcutil (в отличие от wsdl.exe, который использовался для ASMX-сервисов) предназначена для генерации клиентского кода, а не сервисного.

Итак, что же дает нам WSCF.blue. Основное это:

• WSDL Wizard - создание WSDL файла на основе XSD схем;
• Data Contract Generator - создание .Net типов/классов на основе XSD типов;
• Service/Endpoint Stub (SVC) Generator - генератор сервисного кода;
• Client Proxy Generator - генераторно клиентского прокси.

Данный подход (Schema-First Contract-First) имеет свои плюсы и минусы, так же как и любой другой подход.

Приведем пример "минуса" code-first разработки - рекурсивные объявления (cyclic graphs). Используя подход code-first можно объявить следующую структуру (пример взят из стать "Schema-based Development with Windows Communication Foundation"):

public class OrderItem
{
        public Order Order { get; set; }
}

public class Order
{
        public List<OrderItem> Items { get; set; }
}

В XML это может выглядеть вот так:

<Order>
  <Items>
    <OrderItem>
      <Order>
        <Items>
          <OrderItem>
            ///бесконечно вложенные элементы
          </OrderItem>
        </Items>
      </Order>
    </OrderItem>
  </Items>
</Order>

Это не означает, что данную структуру никаким образом нельзя представить через XML, просто это потре...