Natale

На днях анонсирована финальная версия модуля URL Rewriter для IIS:

• интуитивно понятный URL адрес
  URL Rewriter позволяет задавать различные правила (включая регулярные выражения) для преобразования сложных URL-адресов в "красивые" веб-адреса страниц, которые значительно удобнее как для клиентов, так и для индексации сайта поисковыми системами;
• простая интеграция с IIS
  URL Rewriter автоматически интегрируется в существующий и настроенный IIS.

Подробности по ссылке Free URL Rewriter.

#Центр компьютерного обучения «Специалист», Интернет-супермаркет ПО Softkey и компания Microsoft 15 марта с 15.00 до 16.00 проводят онлайн-семинар, посвященный знакомству с Visual Studio 2010 и .NET 4.0.

Преимущества Visual Studio 2010:

• новые средства прототипирования, моделирования и визуального конструирования позволяют создавать новаторские приложения для Windows и Интернет;
• возможность совместного творчества и обмена идеями с помощью SketchFlow в Microsoft Expression® Studio и Team Foundation Server;
• преимущества, обеспечиваемые средствами многоядерного программирования и разработки "облачных" приложений.

Вебинар будет полезен разработчикам, архитекторам ПО, руководителям проектов и IT-отделов, IT-специалистам. В рамках данного вебинара Вы узнаете о:

• новых возможностях инструментов для работы на платформе .Net 4.0;
• изменениях в языках С# и VB.Net (динамические типы, ковариантность, именованные параметры);
• VS 2010 - сравнение версий VS, расширяемость, удобство использования;
• изменениях в самой платформе: CLR 4.0, безопасность, библиотека классов.

Для регистрации воспользуйтесь этой ссылкой.

В ближайших нескольких постах предлагаю ознакомиться с новыми возможностями в 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 использовался BasicHttpBinding. ProtocolMapping поддерживает иерархическое определение, т.е. machine.config → rootweb.config → web.config и т.д.. Это позволяется определить сопоставление как глобально, так и локально.

<protocolMapping>
  <add scheme="http" binding="basicHttpBinding"/>
  <add scheme="net.tcp" binding="netTcpBinding"/>
  <add scheme="net.pipe" binding="netNamedPipeBinding"/>
  <add scheme="net.msmq" binding="netMsmqBinding"/>
</protocolMapping>

или

<protocolMapping>
  <add scheme="http" binding="basicHttpBinding"/>
  <add scheme="net.tcp" binding="netTcpBinding"/>
</protocolMapping>
<protocolMapping>
  <clear scheme="http" />
  <add scheme="http" binding="customBinding"
   bindingConfiguration="binaryHttp" />
</protocolMapping>
<bindings>
  <customBinding>
    <binding name="binaryHttp">
      <binaryMessageEncoding/>
      <httpTransport/>
    </binding>
  </customBinding>
</bindings>

Стандартные endpoint (атрибут kind) - позволяет для конечных точек (endpoint) определить набор постоянных значений (значений по умолчанию). Например, конечная точка (endpoint) метаданных всегда реализует контракт IMetadataExchange, тогда как WebHttpEndpoint всегда соответствует определенное поведение (behaivor). Стандартные конечные точки (endpoint) как раз позволяют определить набор значений по умолчанию единожды и далее ссылаться на созданную стандартную конечную точку (endpoint), именованную сущность. Стандартная конечная точка (endpoint) может быть задана на любом уровне иерархии.

<services>
  <service>
    <endpoint isSystemEndpoint="true" kind="udpDiscoveryEndpoint" />
  </service>
</services>
<standardEndpoints>  
  <udpDiscoveryEndpoint>
     <standardEndpoint multicastAddress="soap.udp://239.255.255.250:3702" /> 
  </udpDiscoveryEndpoint>
</ standardEndpoints >

.SVC-less конфигурация – позволяет не создавать отдельно файл .svc для сервиса, а определить соответствие между адресом сервиса и контрактом, который он реализует, на логическом уровне (web.config).

<system.serviceModel>
    <serviceHostingEnvironment>      
      <serviceActivations>
        <add relativeAddress="Calculator.svc" 
         service="CalculatorService"/>
      </serviceActivations>
    </serviceHostingEnvironment>
    <services>
      <service name="CalculatorService">
        <endpoint binding="webHttpBinding"
           contract="ICalculatorService" />        
      </service>
    </services>
</system.serviceModel>

Веб-каст с примерами по обсуждаемым возможностям можно найти на портале TechDays.ru - "WCF 4.0 в примерах. Часть 1.".

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".

Если запустить приведенный пример и воспользоваться HTTP сниффером, то можно увидеть следующую информацию при обмене сообщениями:

В заголовке сообщения в соответствие со спецификацией WRAP указано "WRAP access_token=…".

Для проверки подлинности сообщения (HMAC) применяется специальная хэш-функция, это позволяет получателю убедиться, что в процессе передачи никакая часть сообщения не была изменена какой-либо третьей стороной.

На выходе получаем токен авторизации, в котором содержатся доступные клиенту разрешения:

<ViewClaims xmlns="urn:azuretraining" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <ViewClaim>
    <ClaimType>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name</ClaimType>
    <Value>SharedSecretUser</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/role</ClaimType>
    <Value>operator</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/action</ClaimType>
    <Value>shutdown</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/action</ClaimType>
    <Value>selftest</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/Issuer</ClaimType>
    <Value>https://leastprivilege.accesscontrol.windows.net/</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/Audience</ClaimType>
    <Value>http://localhost:9999/Service.svc</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/ExpiresOn</ClaimType>
    <Value>1266954106</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
  <ViewClaim>
    <ClaimType>http://swtclaims/HMACSHA256</ClaimType>
    <Value>SM91VrORhmkWe9FgHu83+45yvDipeDLoM7lK/gVfG/8=</Value>
    <Issuer>https://leastprivilege.accesscontrol.windows.net/</Issuer>
  </ViewClaim>
</ViewClaims>

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, просто это потребуется больше усилий: использовать DataContractSerializer и IsReference свойство (через Reflection) для DataContractAttribute, см. DataContractAttribute.IsReference.

Приведем пример "минуса" schema-first разработки: автоматическое обновления кода сервиса при изменении его описания (получается, что не такое будет обновление и "автоматическое").

На самом деле, выбор подхода зависит во многом от решаемой задачи. Иногда эксперты советуют для сервисов, которые изначально предполагаю взаимодействие с другими платформами, генерировать сначала WSDL/XSD, а на его основе код. Если же WCF сервис рассчитан в большей степени на .Net среду, то стандартного подхода будет вполне достаточно. Для себя я предпочитаю все-таки использовать обычно стандартный подход, а в случае необходимости «тюнинговать» сериализацию WSDL и SOAP.

Часть 3: WSDL и document/literal

Итак, WSDL описывает веб-сервис, а WSDL binding описывает, каким образом сервис взаимодействует с протоколом SOAP, т.е. по каким правилам формируются SOAP сообщения. WSDL SOAP binding может соответствовать Remote Procedure Call (RPC) или document стилю. К этому еще добавляются encoded или literal свойства сериализации. Итого получаем четыре возможных варианта (на самом деле пять, т.к. еще есть document/literal wrapped), которые определяют каким образом WSDL binding "преобразовывается" в SOAP сообщение.

Document : <soap:Body> содержит один или несколько дочерних элементов (частей), <soap:Body> содержит те элементы, относительно которых договорились (знают) отправитель и получатель, т.е. других специальных указаний нет.
RPC: RPC подразумевает, что <soap:Body> содержит элемент с именем метода или удаленных процедур, которые будут вызываться. В свою очередь, этот элемент содержит элемент для каждого параметра процедуры/метода.

Endcoded: сериализация выполняется в соответствии со спецификацией SOAP. Правила указывают, каким образом должны быть сериализованы объекты, массивы и т.п.

Literal: сериализация данных выполняется в соответствии со некой схемой (например, W3C XML Schema).

Давайте посмотрим на примеры, чтобы на практике понять различия.

RPC/encoded

<soap:envelope> 
   <soap:body> 
      <myMethod> 
         <x xsi:type="xsd:int">5</x> 
         <y xsi:type="xsd:float">5.0</y> 
      </myMethod> 
   </soap:body> 
</soap:envelope> 

RPC/literal

<soap:envelope> 
   <soap:body> 
      <myMethod> 
         <x>5</x> 
         <y>5.0</y> 
      </myMethod> 
   </soap:body> 
</soap:envelope> 

Document/encoded
Исключаем, т.к. не поддерживается WS-I спецификацией.

Document/literal

<soap:envelope> 
   <soap:body> 
      <Element1>5</Element1> 
      <Element2>5.0</Element2> 
   </soap:body> 
</soap:envelope>

Document/literal wrapped

<soap:envelope> 
   <soap:body> 
      <myMethod> 
         <x>5</x> 
         <y>5.0</y> 
      </myMethod> 
   </soap:body> 
</soap:envelope>

По умолчанию WCF использует document/literal wraped представление, тогда как другие платформы могут использовать, например, rpc/literal. Для конечных клиентов и прокси все преобразования должны быть прозрачны, т.е. SOAP ответ ответы/запросы должны генерировать автоматически в соответствии с тем типом, который объявлен в WSDL сервиса. Но, к сожалению, так бывает не всегда и иногда возникают ошибки, связанные с тем, что та или иная платформа по умолчанию использует другой тип, а не тот, что объявлен в WSDL стороннего сервиса. Что можно сделать в такой ситуации? Например, указать WCF использовать RPC/encoded (и в очередной раз мы будем использовать XmlSerializer):

[OperationContract]  
[XmlSerializerFormat(Style = OperationFormatStyle.Rpc, Use = OperationFormatUse.Encoded)]  
string RPCEncoded(int value)  

Бесплатный Online Вебинар: Планирование, отслеживание и исполнение проектов с использованием Visual Studio 2010, 12.02.2010. Более подробная информация доступна по ссылке.

Часть 2: WSDL и параметры qualified и unqualified

WSDL – это XML формат, использующийся для описания веб-сервисов. Поэтому вспомним некоторые правила формирования XML схемы, в частности, правила описания элементов и атрибутов.

В XML схеме для элементов element и attribute то, что помещается в целевое пространство имен, регулируется атрибутом form. При отсутствии такого атрибута управление передается набору значений по умолчанию в атрибутах elementFormDefault и attributeFormDefault, находящихся в корневом элементе schema. При отсутствии явного задания значений по умолчанию в силу вступают неявные значения по умолчанию: к пространству имен относятся только элементы, определенные глобально. Т.е. каждый элемент может явным образом содержать пространство имен или его не содержать, это и определяется значением атрибута elementFormDefault. Атрибут elementFormDefault может иметь значения qualified и unqualified (по умолчанию). В WCF принято значение qualified.

Пример различия между qualified и unqualified:

<MyClass xmlns:a="http://mynamespace">
   <MyValue>Unqualified</MyValue>
</MyClass>

<MyClass xmlns:a="http://mynamespace">
   <a:MyValue>Qualified</a:MyValue>
</MyClass>

Вы, наверное, спросите: почему же это так важно? Дело в том, что для XML парсеров подобное различие в описании может иметь очень большое значение. Настолько большое, что это может привести к ошибкам при обращении к веб-сервису и некорректно сгенерированному прокси.

Второй ожидаемый вопрос: как в WCF установить значение elementFormDefault в unqualified. Для этого придется использовать XmlSerializer вместо применяемого по умолчанию DataContractSerializer. Использование XmlSerializer позволит Вам контролировать получаемый на выходе XML, но в то же время это потребуется от Вас самостоятельно прописывать правила сериализации (что, правда, не очень утомительно).

Часть 1: WSDL и элемент xsd:import

Интероперабильность можно рассматривать с различных позиций, поэтому предлагаю остановиться на наиболее простом (как казалось бы) варианте – совместимость на основе стандартов, применительно к веб-сервисам, на WS-* спецификациях.

WCF – это платформа, опирающаяся и поддерживающая стек протоколов WS-*. Список протоколов поддерживаемых на момент написания данного поста можно найти здесь – "Web Services Protocols Supported by System-Provided Interoperability Bindings". В частности, нас интересует категория метаданных - WSDL: "WSDL 1.1. WCF uses Web Services Description Language (WSDL) to describe services."

В соответствие со спецификацией "Web Services Description Language (WSDL) 1.1" WSDL описание может содержаться как в едином файле, так и в нескольких. Во втором случае в основном документе представлены ссылки на другие секции описания, которые могут быть расположенные отдельно: "The use of the import element allows the separation of the different elements of a service definition into independent documents, which can then be imported as needed. This technique helps writing clearer service definitions, by separating the definitions according to their level of abstraction. It also maximizes the ability to reuse service definitions of all kinds. As a result, WSDL documents structured in this way are easier to use and maintain."

Соответственно каждый вендор для своей платформы может выбрать любой вариант. Для WCF, в частности, используется второй подход, основанный на импортировании схем описания (т.е. второй вариант). Обратите внимание, что в примере ниже присутствует элемент xsd:import.

<?xml version="1.0" encoding="utf-8" ?> 
<wsdl:definitions 
name="Service1" targetNamespace="http://tempuri.org/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" 
xmlns:tns="http://tempuri.org/" 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" 
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" 
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" 
xmlns:wsa10="http://www.w3.org/2005/08/addressing" 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">
<wsp:Policy>
   ...
</wsp:Policy>
<wsdl:types>
  <xsd:schema targetNamespace="http://tempuri.org/Imports">
  <xsd:import schemaLocation="http://localhost:8000/Service1?xsd=xsd0" namespace="http://tempuri.org/" /> 
  <xsd:import schemaLocation="http://localhost:8000/Service1?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/" /> 
  <xsd:import schemaLocation="http://localhost:8000/Service1?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/WCF1" /> 
  </xsd:schema>
</wsdl:types>
   ...
</wsdl:definitions>

Другие технологии иногда используют, наоборот, первый подход (единый файл). Что не должно, теоретически, создавать проблем, т.к. в соответствии со спецификацией оба варианта равноправны, но… Иногда это приводит к несовместимости: генерация прокси-классов по WSDL не может быть выполнена корректно некоторыми утилитами.

И что же тогда делать? Самый правильный ответ – следовать спецификации и поддерживать WSDL как «первого» типа, так и «второго». Но если исходить из практики и того, что реализация требований спецификации может занять время, то можно воспользоваться резервным вариантом - публикацией «плоского» WSDL для WCF, т.е. когда все элементы описаны в едином документе. Christian Weyer создал специальное поведение (behavior), которое публикует описание WCF-сервиса как «плоский» WSDL, см. "Improving WCF Interoperability: Flattening your WSDL". Обратите внимание, что теперь элемент xsd:import отсутствует и все элементы определены в одном WSDL.

<?xml version="1.0" encoding="utf-8" ?> 
<wsdl:definitions 
name="Service1" targetNamespace="http://tempuri.org/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" 
xmlns:tns="http://tempuri.org/" 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" 
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" 
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" 
xmlns:wsa10="http://www.w3.org/2005/08/addressing" 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">
<wsp:Policy>
   ...
</wsp:Policy>
<wsdl:types>
   <xsd:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
      ...
   </xsd:schema>
   <xsd:schema elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/WCF1" xmlns:tns="http://schemas.datacontract.org/2004/07/WCF1">
      ...
   </xsd:schema>
   <xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/2003/10/Serialization/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.microsoft.com/2003/10/Serialization/">
      ...
   </xs:schema>
</wsdl:types>
   ...
</wsdl:definitions>