Похоже, я могу свободно переключаться между следующими тремя разными версиями одного и того же 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 в методы в стиле TAP SomeMethodAsync, чтобы использовать async/await в их реализации и, таким образом, улучшить масштабируемость службы WCF, не нарушая работу существующих клиентов.
Кроме того, известны проблемы с масштабированием службы WCF в .NET 3.5 и .NET 4.0. Они описаны в статье MSKB «Служба WCF может медленно масштабироваться под нагрузкой» и статье CodeProject " Настройка WCF для создания высокомасштабируемого асинхронного REST API ». По сути, было недостаточно реализовать API контрактов службы как естественно асинхронные, среда выполнения WCF все еще блокировала поток запроса.
- Кто-нибудь знает, была ли эта проблема решена для .NET 4.5.x "из коробки"? Или еще требуются дополнительные настройки?
int SomeMethod(int arg), либоasync Task<int> SomeMethodAsync(int arg), и оба будут идентичны пользователю. Оба будут синхронными на стороне клиента. - person Timothy Shields schedule 26.03.2014