Кажется, я могу свободно переключаться между тремя различными версиями одного и того же API интерфейса контракта WCF, не нарушая клиентов:
[ServiceContract]
interface IService
{
// Either synchronous
// [OperationContract]
// int SomeMethod(int arg);
// Or TAP
[OperationContract]
Task<int> SomeMethodAsync(int arg);
// Or APM
// [OperationContract(AsyncPattern = true)]
// IAsyncResult BeginSomeMethod(int arg, AsyncCallback callback, object state);
// int EndSomeMethod(IAsyncResult ar);
}
Существующее тестовое клиентское приложение продолжает работать без перекомпиляции или трогания. Если я перекомпилирую службу и повторно импортирую ее ссылку в клиентское приложение, определение WSDL останется тем же самым, 1:1.
Мои вопросы:
- Является ли это законным поведением, на которое я могу положиться? Насколько он документирован?
Идея состоит в том, чтобы преобразовать набор синхронных методов SomeMethod -style в методы TAP SomeMethodAsync -style, использовать async/await в своей реализации и тем самым улучшить масштабируемость службы WCF, не нарушая существующих клиентов.
Кроме того, были известны проблемы с масштабированием службы WCF в .NET 3.5 и .NET 4.0. Они задокументированы в статье MSKB "Служба WCF может медленно увеличиваться при загрузке" и в статье CodeProject "Тонкая настройка WCF для сборки высоко масштабируемый асинхронный REST API" . В принципе, было недостаточно для того, чтобы API-интерфейсы сервисных контрактов были естественно асинхронными, среда выполнения WCF все еще блокировала поток запросов.
- Кто-нибудь знает , если эта проблема была исправлена для .NET 4.5.x, из коробки? Или необходимы дополнительные настройки?
