Обеспечение интероперабельность между платформами должны быть легко и просто, правда? Но, к сожалению, это не всегда так. Но Ваш feedback позволит в значительной мере улучшить совместимость и взаимодействие между платформами, в частности по средствам WCF. Пожалуйста, отправьте свой отзыв до 15 июля!

Опрос: http://mymfe.microsoft.com/WCF/Feedback.aspx?formID=283

Основная задача Inproc SxS - это решить вопрос совместимости и параллельного использования модулей/надстроек (Add-In и т.п.), написанных на .Net различных версий. Данный вопрос хорошо освещен в следующей статье "In-Process Side by Side (Part1)", поэтому не будем подробно на этом останавливаться, а приведем несколько примеров использования In-Process Side-by-Side для Office Add-In:

1. Открытие существующих документов Office в новой версии пакета MS Office с возможностью использования Office Add-In, написанных для предыдущих версий пакета MS Office. Теперь данный сценарий может быть реализован корректно: благодаря Inproc SxS новые и старые Add-In’ы могут работать совместно в рамках одного экземпляра MS Office.
2. Обратная ситуация: открытие новых документов в предыдущей версии пакета MS Office с возможностью использования Office Add-In, написанных для новой версии пакета MS Office. Теперь данный сценарий может быть реализован корректно: благодаря Inproc SxS новые Add-In'ы, например, для CLR vNext (условно следующей версии .Net) и "старые" Add-In'ы (CLR 4.0) будут работать совместно корректно.

Важно понимать, что Inproc SxS - это решение вопроса совместимости модулей/надстроек, написанных на различных версиях .Net. Inproc SxS - это не замена миграции или решения вопроса совместимости приложения целиком с новой версией .Net.

Рассмотрим следующие два сценария:

1. У нас есть библиотека (а не Add-In), написанная на .Net 3.5. Мы планируем ее использовать в нашем новом проекте и приложении, которое написано на .Net 4.0. В этом случае нам необходимо убедиться, что библиотека, написанная на .Net 3.5, корректно выполняется в среде .Net 4.0, т.е. режим Inproc SxS в данном случае не решит напрямую проблем совместимости, если таковые возникнут, т.к. "Library developers and consumers. Side-by-side hosting does not solve the compatibility problems that library developers face. A library that is directly loaded by an application - either through a direct reference or through an Assembly.Load call - continues to use the runtime of the AppDomain it is loaded into."
2. У нас есть приложение, написанное на .Net 3.5. Мы планируем разрабатывать новые библиотеки для приложения на .Net 4.0. В этом случае нам необходимо мигрировать приложение на .Net 4.0 (аналогично предыдущему примеру), т.к. "If you have an application that was built using an earlier runtime and a library that was built using the .NET Framework 4, you must force your application to also use the .NET Framework 4." Net 4.0 поддерживает режим обратной совместимости, поэтому миграция может быть выполнена достаточно просто, например, даже без перекомпиляции приложения, а только указанием в конфигурационном файле, что требуется использовать CLR 4.0.

   <configuration>
      <startup> 
         <supportedRuntime version="v4.0" />
      </startup>
   </configuration>

Решение: кастомная привязка (binding) c параметром authenticationMode, установленным в значение KerberosOverTransport.

<customBinding>
   <binding name="kerberosCustomBinding">
      <security authenticationMode="KerberosOverTransport" />
      <httpsTransport />
   </binding>
</customBinding>

Примечание: при подобной конфигурации необходимо прописать для учетной записи, от которой работает WCF сервис (пул IIS), SPN (Service Principal Name), например, setspn.exe -a http\<serverFQDN> <domain\wcfserviceaccount>. А в конфигурационном файле клиента выставить соответствующие значение (<servicePrincipalName> тэг), например, <servicePrincipalName value="http\<serverFQDN>">, где <serverFQDN> - полное доменное имя сервера, а <domain\wcfserviceaccount> - доменная учетная запись, от имени которой запущен WCF сервис.

IServiceContract proxy = ChannelFactory<IServiceContract>.CreateChannel(binding, address);
((IClientChannel)proxy).Open(TimeSpan.FromMinutes(1));
proxy.Method1();
proxy.Method2();

Для выполнения данной задачи нам необходимо выполнить преобразование к IContextChannel интерфейсу и установить значение параметра OperationTimeout, либо напрямую получить доступ к InnerChannel и выставить значение OperationTimeout.

proxy.Service1Client client = new proxy.Service1Client();
client.InnerChannel.OperationTimeout = TimeSpan.FromMinutes(5);
Console.WriteLine(client.Method1());
client.InnerChannel.OperationTimeout = TimeSpan.FromMinutes(10);
Console.WriteLine(client.Method2());
Console.ReadLine();

WebGet/WebInvoke - специальные атрибута операции сервиса, которые определяют, что данная операция может быть вызвана по HTTP GET или HTTP POST соответственно, т.е. не требуется формирования SOAP конверта, а достаточно стандартного HTTP запроса. Обычно операция сервиса вызывается с некоторыми входными параметрами, в данном случае входные параметры могут быть переданы либо через URL (query string), либо через тело HTTP запроса (post data). Для удобства извлечения значений входных параметров из URL можно использовать специальную конструкцию – UriTemplate, позволяющую описать структуру и разбор URL, по которому вызвается сервис.

[WebGet(UriTemplate = "Users/{userName}")]   
public User GetUser(string userName)
{   
}
[WebInvoke(UriTemplate = "Tasks/{id}", Method = "PUT")]  
public Task UpdateTask(string id, Task task)  
{  
}

В примере операция GetUser публикуется по GET и принимает входной параметр (из URL) userName. Обратите внимание, что преобразование типа входного параметра к srting производится автоматически, т.е. вместо string может быть указан любой другой простой тип, например, int.
Операция UpdateTask публикуется по метод HTTP PUT, с входным параметром id все аналогично вышеописанной ситуации, входной параметр task извлекается из тела (body) HTTP запроса. При необходимости Вы имеете возможность работать с телом HTTP запросом напрямую, для этого в параметрах метода потребуется указать единственный входной параметр типа Steam.

Help-страница – это специальная страница, содержащая информацию о REST WCF сервисе, в частности, название операций, формат запроса/ответа, схемы данных и т.п. (чем-то напоминает WSDL, хотя важно помнить, что это не WSDL). Для созданного WCF REST сервиса подобная страница создается автоматически, при необходимости она может быть кастомизирована.

<configuration>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
    <behaviors>
      <endpointBehaviors>
        <behavior name="HelpBehavior">
          <webHttp helpEnabled="true" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="CounterResource">
        <endpoint behaviorConfiguration="HelpBehavior"
                  binding="webHttpBinding"
                  contract="CounterResource" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

В примере включается автоматическая генерация Help-страницы, в этом случае страница будет доступна по следующему адресу http://server/restwcfservice/help.

Поддержка JSON/JSONP. Помимо XML формата запроса/ответа WCF REST поддерживает и другие форматы, например: JSON, JSONP. Возможно включение и поддержки ATOM, но для этого на текущий момент потребуется небольшая кастомизация. Формат возвращаемых данных клиенту может быть определен автоматически за счет параметра automaticFormatSelectionEnabled, т.е. Вам не потеряется создавать несколько методов или разветвленную логику для того, чтобы выдать клиенту ответ в предпочтительном для него формате. Важно, что automaticFormatSelectionEnabled применяется к исходящему запросу, т.е. на данный момент ограничить входящие запросы конкретным форматом (JSON или XML) нельзя, запрос в любом формате будет принят сервисом. Логика автоматического выбора формата ответа достаточно проста и логична:

1. Анализируется HTTP Accept заголовок HTTP запроса. Если HTTP Accept отсутствует, то переходим к следующему пункту.
2. Анализируется content-type запроса. Если тело HTTP запроса отсутствует (пустое) или content-type имеет поддерживаемое значение, то переходим к следующему пункту.
3. Ответ выдается в формате по умолчанию для операции.

<configuration>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
    <behaviors>
      <endpointBehaviors>
        <behavior name="HelpBehavior">
          <webHttp helpEnabled="true" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="CounterResource">
        <endpoint behaviorConfiguration="HelpBehavior"
                  binding="webHttpBinding"
                  contract="CounterResource" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

В примере в конфигурационном файле включается опция автоматического определения формата ответа REST сервиса.

Возможность WCF автоматического формирования ответа в приемлемом для клиента формате очень удобна, и не менее удобная и полезна поддержка JSONP формата, которая включена в WCF REST. В чем отличие JSON от JSONP? JSONP (JSON Padding) является расширением JSON, когда имя функции обратного вызова указывается в качестве входного аргумента [wiki]. JSOPN используется для кросс доменных вызовов, см. JSONP & JSONPP.

WebFaultException - это специальный класс для возврата ошибки (exception) клиенту. WebFaultException наследуется от стандартного FaultException, который определяет формат SOAP исключения. Т.к. REST сервис – это не стандартный SOAP сервис, то и информирование клиента об исключение должно производиться иначе, т.к. SOAP-исключение, обернутое в SOAP конверт, клиент просто не распознает. Поэтому для REST сервисов используется WebFaultException. Отличительной особенностью WebFaultException является то, что ошибка возвращается клиенту в приемлемом для него формате, т.е. если входной запрос пришел в формате JSON, то и информация об ошибке/исключении так же возвратится в формате JSON. WebFaultException помимо описания ошибки имеет и еще одно поле (которое отсутствует в SOAP FaultException) – это статус HTTP (HttpStatusCode), т.к. для REST это важно.

if (user == null) 
{ 
	throw new WebFaultException<string>( 
            string.Format("There is no user with the userName &apos;{0}&apos;.", userName), 
            HttpStatusCode.NotFound); 
}

В примере на клиента возвращается текст ошибки и HTTP статус NotFound.

ASP.NET Routing. WCF REST сервисы поддерживает стандартный ASP.NET Routing (для этого режим совместимость с ASP.NET - aspnetcompatibilityenabled - должен быть включен в конфигурационном файле).
Маршрутизация ASP.NET позволяет использовать URL-адреса, не сопоставляемые с определенными файлами на веб-узле. Подробнее о маршрутизации ASP.NET можно прочесть в статье "Маршрутизация ASP.NET".

private void RegisterRoutes(RouteCollection routes)
{
    routes.Add(new ServiceRoute("Customers", new WebServiceHostFactory(), typeof(Service))); 
}

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    <add name="UrlRoutingModule
     type="System.Web.Routing.UrlRoutingModule, System.Web />
  </modules>
  <handlers>
    <add name="UrlRoutingHandler" path="UrlRouting.axd"	preCondition="integratedMode" verb="*" />   
  </handlers>
</system.webServer>

В примере для WCF REST сервиса подключается в web.config модуль ASP.NET Routing – UrlRoutingModule, а так же в методе RegisterRoutes опредеяются правила маршрутизации (с входным запросом по URL http://server/wcfrestservice/customers сопоставляется операция REST сервиса).

Кэширование. WCF REST сервисы поддерживает стандартный механизм кэширования ASP.NET (для этого режим совместимость с ASP.NET - aspnetcompatibilityenabled - должен быть включен в конфигурационном файле). Для определения параметров кэширования исходящего ответа к операции добавляется атрибут AspNetCacheProfile, в котором указывается имя профиля кэширования, тогда как сам профиль определяется в web.config. Следующие типы кэширования поддерживаются: Any | Client | Downstream | Server | None | ServerAndClient. Интересными являются следующие:

• Client – кэширование данных на стороне клиента, т.е. кэшируемые данные не разделяемые;
• Server – кэширование данных на стороне сервера, т.е. кэшируемые данные разделяемые;
• Downstream - кэширование данных на стороне, например, прокси-сервера.

[AspNetCacheProfile("CacheFor60Seconds")]
[WebGet(UriTemplate=XmlItemTemplate)]
public Counter GetItemInXml()
{
    return HandleGet();
}

<configuration>
  <system.web>
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
        <add name="CacheFor60Seconds" duration="60" varyByParam="format" />
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
  </system.web>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
  </system.serviceModel>
</configuration>

В примере устанавливается режим совместимости с ASP.NET, а так же режим кэширования: данные кэшируются на сервере (по умолчанию), данные актуальны в течение одной минуты и зависят от входящего формата запросам, т.е. для JSON формата входящего запроса кэшируется один ответа, а для XML – другой.

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

Интеграция между WCF и WF существовала и в версии .Net 3.5. Например, можно было опубликовать WF как WCF сервис или взывать синхронно/асинхронно WCF из созданного рабочего-процесса (WF). Но контролировать процесс выполнения WF было не так просто, помимо этого существовала вторая "проблема" - Workflow Runtime потребляла немало ресурсов при инициализации или реинициализации (возобновления работы) экземпляров WF сервисов, поэтому достаточно часто бизнес-логика реализовывалась в виде библиотек и классов, а не рабочих процессов.

В версии WCF 4.0 и WF 4.0 все эти замечания были учтены. В .Net 4.0 Workflow Runtime не только расширила свои возможности, но и была полностью переработана (в том числе и повысилась производительность). Далее поговорим о тех преимуществах и "новинках", которые связаны с интеграцией WCF и WF.

WorkflowServiceHost - специальный класс, обеспечивающий запуск/выполнение WF сервисов из Вашего приложения в случае, если WF сервис не размещен на IIS/WAS (на самом деле IIS/WAS так же используют WorkflowServiceHost, но это является прозрачным для конечного разработчика). WorkflowServiceHost используется для запуска WF, конфигурирования конечных точек (endpoint) и настроек безопасности, а так же для запуска слушателей (listener) входящих запросов.

WorkflowServiceHost host = new 	WorkflowServiceHost("HelloWorld.xamlx", new Uri("http://localhost:8080/helloworld"));
host.AddDefaultEndpoints();
host.Description.Behaviors.Add(new ServiceMetadataBehavior{ HttpGetEnabled = true });
host.Open();

В приведенном примере из консольного приложения запускается хост для декларативного WF сервиса (*.xamlx), задается URI адрес сервиса, инициализируются конечные точки (endpoint) по умолчанию и начинается прослушивание входящих сообщений.

WorkflowControlEndpoint - конечная точка, позволяющая управлять экземплярами WF, в частности это команды Run, Suspend, Resume, Terminate, Cancel, и Abandon.

WorkflowServiceHost host = new WorkflowServiceHost("HelloWorld.xamlx",
	new Uri("http://localhost:8080/helloworld"));
host.AddDefaultEndpoints();
WorkflowControlEndpoint wce = new WorkflowControlEndpoint
	(new NetNamedPipeBinding(),
	new EndpointAddress("net.pipe://localhost/helloworld/WCF"));
host.AddServiceEndpoint(wce);
host.Open();
IWorkflowCreation creationClient = new ChannelFactory<IWorkflowCreation> 
	(creationEndpoint.Binding, creationEndpoint.Address).CreateChannel();
Guid instanceId = creationClient.CreateSuspended(null);
WorkflowControlClient controlClient = new WorkflowControlClient(controlEndpoint);
controlClient.Unsuspend(instanceId);

В данном примере объявляется специальная конечная точка (endpoint) - WorkflowControlEndpoint, доступная по именованному каналу (named pipe). Далее создается канали взаимодействия (CreareChannel) и происходит обращение к WorkflowControlClient, позволяющему посылать команду управления WF сервису, в частности конкретному экземпляру (за счет указания уникального идентификатора экземпляра, instanceId).

Корреляция - это специальный механизм сопоставления конкретного экземпляра WF (а так же конкретных активностей внутри WF) с событиями/данными, адресованными именно данному экземпляру. Например, у нас есть WF, который запускается, выполняет какие-либо действия, посылает запрос во внешнюю систему и ожидает ответа от этой внешней системы. Очевидно, что одновременно могу существовать несколько экземпляров подобного WF, созданные различными пользователями. Каждый из этих активных экземпляров ожидает "своего" ответа от внешней системы, который зависит от данных именного данного экземпляра WF. Механизм корреляции позволяет Workflow Runtime верно сопоставить экземпляр WF и предназначенную ему информацию.

В основе механизма корреляции лежит такое понятие как токен корреляции, который уникален для каждого экземпляра WF.

WF 4.0 поддерживает следующие виды корреляции:

• на основе протокола (protocol-based): транспортного уровня (request-reply correlation) или контекста (context correlation);
• на основе бизнес-логике/бизнес-данных (content-based): собственные (пользовательские) данные в SOAP сообщении (content correlation).

Примером корреляции первого вида (protocol-based) типа запрос/ответ (request-reply correlation) может служить, например, вызов внешнего веб-сервиса, т.е. исходящему HTTP-запросу соответствует конкретный ответ HTTP-ответ.

Для корреляции первого вида (protocol-based), основанной на контексте (context correlation) необходимо использование привязок (binding), поддерживающих контекстный обмен сообщений BasicHttpContextBinding, WSHttpContextBinding и NetTcpContextBinding.

В этих двух случаях механизм корреляции практически прозрачен для разработчика, т.е. сопоставление выполняется автоматически за счет транспортного уровня или контекста WCF.

В случае корреляции, основанной на бизнес-логике (content-based correlation), разработчик явным образом указывает какие данные SOAP сообщения используются для сопоставления. Например, это может быть уникальный идентификатор заказа.

Получается, что теперь понятие корреляции - это не только внутренний механизм WF, а скорее разделяемый механизм между WCF и WF (разбор SOAP сообщения, взаимодействие с привязками (binding) и т.п.).

Более подробную информация и примеры по данной теме Вы можете найти в одной из моих предыдущих заметок - "Корреляция в WF-сервисах 4.0".

Variable<string> Item = new Variable<string>();
Variable<CorrelationHandle> OrderHandle = new Variable<CorrelationHandle>();
Receive StartOrder = new Receive
{
    CanCreateInstance = true,
    ServiceContractName = OrderContractName,
    OperationName = "StartOrder"
};

SendReply ReplyToStartOrder = new SendReply
{
    Request = StartOrder,
    CorrelationInitializers =
    {
        new ContextCorrelationInitializer
        {
            CorrelationHandle = OrderHandle
        }
    }
};

SendReply/ReceiveReply - это новые активности, упрощающие интеграцию между WCF и WF. Данные активности моделируют сервисные операции получения сообщения и отправки ответного сообщения.

SendReply активность в совокупности с Receive активностью моделирует операцию сервиса запрос/ответ (request-reply). ReceiveReply активность в совокупности с Send активностью может использоваться для вызова внешнего сервиса из создаваемого WF.

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

В ходе анализа были выполнены следующие действия:

1. Включение мониторинга информации о создании файлов, в частности в директории %localappdata% \Temp, подтвердило, что в данной директории создаются временные файлы с именем XCP*.tmp, где * - уникальная последовательность цифр.
2. Создано аналогичное WPF приложение. С его помощью не удалось воспроизвести проблему.
3. Утилитой ProcMon выполнен мониторинг временных файлов, создающихся Internet Explorer.

Причина: использование GZip сжатия HTTP потока в Silverlight.

Пути решения:

1. Периодически выполнять прямой вызов GC.Collect() в Вашем приложении. Например, этот вызов может зависеть таймера, количества выполненных запросов и т.п.
2. Отключить GZip сжатие для HTTP ответов.
3. В Silverlight 4.0 можно так же установить параметр AllowReadStreamBuffering в значение false.

При написании данной заметки обнаружила недавно появившуюся статью в Knowledge Base - "PRB:Silverlight application creates large temporary files when making calls to WebServices", в которой причины возникновения данного поведения описаны более подробно.

Другие ссылки:

• Announcing availability of Visual Studio 2010 and .NET Framework 4;
• Ссылки для загрузки Visual Studio 2010;
• Live keynotes.

WinPE – средства предустановки, это минимальная версия операционной системы Win32 с ограниченными службами, построенная на ядре Windows. Она используется для подготовки компьютера к установке Windows, копирования образа Windows с сетевого файлового сервера и запуска установки Windows.

Среда Windows PE не предназначена для использования в качестве основной операционной системы на компьютере - она служит в качестве изолированной среды предустановки и является встроенным элементом других средств установки и восстановления системы, например программы установки для Windows 7, служб развертывания Windows (Windows DS), пакета средств развертывания операционной системы (OS) сервера SCCM и среды восстановления Windows (Windows RE).

На данный момент последняя версия WinPE – это WinPE 3.0, построенная на ядре Windows 7. Подробнее о WinPE можно прочитать в стать "Что такое Windows РЕ?".

WinPE имеет определенные ограничения, в частности:

• для минимизации размера среды Windows PE в нее включен только ограниченный набор интерфейсов программирования Win32;
• среда Windows PE не поддерживает оболочку Microsoft .NET или среду CLR.

Образ WinPE может быть кастомизирован. Это означает, что в него может быть добавлена поддержка:

• пользовательских скриптов;
• разрешенных дополнительных пакетов, расширяющих стандартную функциональность WinPE.

Для получения более подробной информации смотрите стать "Краткое руководство: создание пользовательского образа Windows PE", "Добавление специального сценария в образ Windows PE" и "Добавление пакета в образ Windows PE".

Из возможностей кастомизации нам с Вами могут быть интересны следующие:

• пакет WinPE-HTA - это поддержка HTML-приложений, позволяющая создавать приложения с графическим интерфейсом пользователя, используя обработчик сценариев Internet Explorer и службы HTML;
• пакет WinPE-Scripting - это поддержка сервера сценариев Windows (WSH), позволяющая производить пакетную обработку файлов с помощью объектов сценариев WSH.

Стоит отметить, что теперь (WinPE 3.0) пакет WinPE-XML входит в базовый файл boot.wim. WinPE-XML - это поддержка программы разбора Microsoft XML (MSXML).

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

1. Перенос логики обращения к Active Directory на сторону выделенного сервера приложений. Т.к. на стороне сервера приложений нет ограничений по использованию .Net, то создадим WCF сервис, решающий эту задачу. Для этого воспользуемся пространством имен System.DirectoryServices.AccountManagement (API AccountManagement), которое доступно в .Net 3.5. System.DirectoryServices.AccountManagement пришло на смены System.DirectoryServices, использовавшемуся в .Net 2.0.
2. Использование MSXML для взаимодействия с WCF сервисом: формирование SOAP запроса и получение/разбор SOAP ответа. Для этого будем использовать объект ServerXMLHTTP. ServerXMLHTTP поддерживает как GET, так и POST.
3. Организация общения через SSL (безопасность на уровне транспорта). С бизнес точки зрения это необходимо, т.к. может WCF сервис может выполнять различные операции, например, некоторые из которых могут требовать аутентификации или принимать в качестве параметров конфиденциальные данные. С точки зрения технической - организовать общение по SSL в данном случае будет проще, чем через безопасность на уровне сообщений (WS-Security), т.к. нам придется работать с SOAP практически напрямую. Примечание: в случае, если шифрование не требуется, то можно вообще обойтись не SOAP WCF сервисом, а REST WCF сервисом, что будет еще проще.

Код на стороне WCF сервиса

[ServiceContract]
public interface IActiveDirectory
{
    [OperationContract, WebInvoke(Method = "POST", BodyStyle = WebMessageBodyStyle.Bare)]
    bool ValidateCredentials(Stream stream);
}

public bool ValidateCredentials(Stream stream)
{
    StreamReader reader = null;
    try
    {
        reader = new StreamReader(stream);
        NameValueCollection values = HttpUtility.ParseQueryString(reader.ReadToEnd(), Encoding.UTF8);
        PrincipalContext pc = new PrincipalContext(ContextType.Domain, values["domain"]);
        return pc.ValidateCredentials(values["username"], values["password"]);
    }
    catch (System.Exception ex)
    {
        throw ex;

    }
    finally
    {
        if (reader != null)
            reader.Close();
    }
}

Код на стороне WinPE

Function ValidateCredentialsPOST(username, password, domain)
    Dim srvXmlHttp, docXML
    Set srvXmlHttp = CreateObject ("MSXML2.ServerXMLHTTP.6.0")
    srvXmlHttp.setoption(2) = 13056 
    srvXmlHttp.Open "POST","https://<AppServerUrl>/<WcfServiceFile.svc>/ValidateCredentials", False
    srvXmlHttp.setRequestHeader "CharSet", "UTF-8"
    srvXmlHttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
    srvXmlHttp.Send "username=" & escape(username) & "&password=" & escape(password) & "&domain=" & escape(domain)
    Set docXML = CreateObject("MSXML2.DOMDocument.6.0")
    docXML.LoadXML (srvXmlHttp.ResponseXML.XML)
    ValidateCredentialsPOST = docXML.text
End Function

Обратите внимание на строку srvXmlHttp.setoption(2) = 13056. Она необходима, чтобы принять SSL сертификат сервера приложений, т.к. игнорировать ошибка проверки подлинности сертификата. А так же на функцию escape, которая необходима для кодирования символов передаваемых параметров.

.Net Assemblies

.Net Performance