Note 1. WSDL and WSE.

Если WebService поддерживает WS-Security, digital signature присоединяется к каждому SOAP-request. С точки зрения WSDL, это означает, по меньшей мере, что WS-Security (и вообще WS-*) requirements должны определяться на уровне . Но WSDL ничего не знает о WSE. Ни на уровне , ни, тем более, на уровне . Как же генериривать WSE-enabled proxy из такого WSDL? Чтобы ответить на этот вопрос, надо просто вспомнить, что и сам System.Web.Services ничего не знает о WSE. Т.е. генерировать proxy на его основе просто бесполезно. Поэтому WSE-enabled proxy строится на основе WSE framework по одному из двух путей: 1). WseWdl2.exe (а с недавнего времени и WseWsdl3.exe) и 2). WSE add-in for VS.NET.

1. WseWsdlNNN.exe - proxy будет построен на основе SoapClient. Имплементация не имеющая никакого отношения к HTTP - прямая дорога в Indigo!


2. VS.Net add-in : если client объявляет поддержку WSE (обычно через Configuration Editor, что приводит, в любом случае, к изменениям в его .config), add-in сгенерирует 2 proxy - обычный, от SoapHttpClientProtocol и WSE-enabled, от WebServicesClientProtocol. Если поддержка WSE не включена на клиенте, второй proxy создаваться не будет, а если включена, то будет даже для тех WebServices, которые созданы без WSE!

В обоих случаях, WSE-enabled proxy строится на основании собственного framework, используя WSDL, как обычно, для описания методов и параметров. Не больше того.

Запутывает дело WS-Policy. Казалось бы, он служит для того, чтобы a-priory предоставить информацию о WS-demands. В самом деле, допустим WebService требует digital signature от Username Token (WS-Security). Откуда клиент должен об этом знать? Из WSDL? Нет. WS-Policy существует как-бы "в обход" расширения WSDL. Т.е. помимо WSDL, сервис должен предоставить интересующимся клиентам свой policy file. С другой стороны, но это уже добавка MS к WS-Policy, (или, я бы сказал, специфическая реализация MS) существует WSE enforcer, который даже не позволит никакому методу быть вызванным, если клиент не записал созданный token в cache. Но это детали реализации, суть же такова : WSDL остался unchanged. Именно по этой причине asmx не может помочь выяснить WSE требования сервиса к клиенту.  Отсюда мораль номер один : distribute your policy.

Признание : я не внимательно читал WSDL 2.0 spec. Возможно, будет связан там с WS-Policy. На мой взгляд, механизм, подобный .disco, решил бы этот вопрос до времени повсеместной адоптации WSDL 2.0.

Note 2. BizTalk Adapter for WSE 2.0

Главная задача адаптера - enable secured HTTP calls for orchestartions, published as WebServices. Для этой цели BizTalk WSE WebServices Publishing Wizard построит policy files, которые (см. предыдущий note) станут извеснтны клиентам. Дело разработчика BizTalk - предоставить свой security token manager (в отдельном assembly), в котором он сможет проверить token. Очень важно, что благодаря WSE enforcer и MS реализации WS-Policy, те клиентские вызовы, которые не включают требуемый token, даже не дойдут до вашего token manager!

С помощью адаптера можно из orchestration  вызывать WSE WebServices. Не совсем понятно, как (без discovery or WSDL 2.0) можно понять, какой token нужен вызываемому WebServic'у. Поэтому отсюда вытекает мораль номер два : be able to read (and understand) at least your own policy.

Note 3. WSE 3.0

Во-первых, доступна только для VS.NET 2005 and .NET Framework 2.0. Во-вторых, WS-Policy значительно изменился в сторону Indigo (а вместе с ним, и WSE Security Settings Wizard). Поддеживается WS-Security 1.1. Сертификаты не шутка - VerySign не даром представлен во всех рабочих группах W3C. Особенное внимание уделено MTOM. Отсюда мораль номер три : be aware of rapidly changes of policy.